SG15 and SG23 both discussed P2947 last week. Has there been new
information published to indicate that it needs to be revisited?

On Mon, Nov 13, 2023 at 10:07 AM Ran Regev via SG21
<sg21_at_[hidden]> wrote:
>
>
> Timur,
>
> Do you want to create a list of issues to be seen by SG15?
>
> I counted:
> 1. https://wg21.link/p2947
> 2. Contract semantics.
>
>
> Ran.
>
>
> On Mon, Nov 13, 2023, 16:06 Ben Boeckel via SG21 <sg21_at_[hidden]> wrote:
>>
>> On Thu, Nov 09, 2023 at 22:09:55 +0200, Ville Voutilainen via SG15 wrote:
>> > On Thu, 9 Nov 2023 at 21:58, Tom Honermann via SG21
>> > > Some regular attendees of SG15 have expressed concerns that a
>> > > contracts design (the MVP) might be accepted for C++26 without
>> > > adequate tooling consideration thereby potentially leading to a
>> > > situation like we have now with modules where we have a language
>> > > feature with significant adoption challenges. I share some of these
>> > > concerns.
>> >
>> > I would hesitate to suggest or leave room for the impression that
>> > modules were standardized without adequate tooling consideration.
>>
>> Well, P1300 was ignored at least (though I didn't search for minutes
>> related to it, the end result is basically "no effect").
>>
>> https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1300r0.pdf
>>
>> We now have a named module system which is isomorphic to Fortran in
>> terms of sophistication in the build graph executor[1]. It is more
>> complicated for build *systems* because Fortran can get away with "this
>> is the one way this module exists" and not have to curate a BMI variant
>> per importer potential. C++ is better in implementation because the
>> compiler can say use *this* BMI instead of having to coordinate with
>> include path search mechanisms.
>>
>> The biggest fallout is that modules support is limited to (not complete,
>> but probably not missing many):
>>
>> - build2
>> - CMake
>> - VS 2022 17.6+
>> - Ninja 1.11.1+
>> - evoke (?)
>> - GNU Make (with GCC; Clang has libcody patches out-of-tree)
>> - llbuild (?)
>> - MSBuild
>> - xmake
>>
>> So we've lost/left behind at least (this is obviously not a
>> comprehensive list):
>>
>> - autotools (no idea)
>> - CMake with any other generator (Makefiles is possible, but needs major
>> surgery)
>> - hand-coded Makefiles
>> - Meson (aware of the work needed but, AFAIK, not finished)
>> - qmake
>> - qubes
>> - Xcode
>>
>> There was also a lack of build system implementation experience before
>> accepting them (I had a set of patches for CMake, GCC, and Ninja at Kona
>> 2019, Boris had a from-the-ground-up build2 system of some vintage
>> around that time, and that's it I believe). AFAIK, other extant build
>> systems were not working on them prior to their publication. Of course,
>> actually trying to land my prototype patches ended up discovering
>> *further* build system semantics that needed hashed out (mainly around
>> installation of module sources) before they could truly be handed off to
>> C++ developers.
>>
>> > Furthermore, some new language facilities just do have adoption
>> > challenges, that's sometimes the nature of the beast. The
>> > tooling-feedback
>> > from e.g. build system developers hasn't thus far revealed a need to
>> > do major design surgery to modules, as far as I have understood.
>>
>> It's mainly been grammar tweaks (e.g., disallowing macro expansion for
>> the key parts of `export module foo;` to avoid…shenanigans). Other than
>> that, suggestions always hit the "what is a file?" limitations of the
>> language standard. Also, if tooling had their way, I suspect header
>> units would be…different. We also have expanded the venerable zoo of
>> extensions that are considered "C++" code:
>>
>> C M c++ cc cpp cxx m mm mpp CPP ixx cppm ccm cxxm c++m
>> ^^^ ^^^ ^^^^ ^^^ ^^^^ ^^^^
>>
>> I've highlighted the new extensions modules has…inspired because the
>> standard can't give any suggestions here. I've also seen another new
>> extension last week that someone asked if CMake would support it and I
>> told them I was going to pretend I didn't see that and asked them to
>> pick from any of the above existing selections instead.
>>
>> > Keeping tooling people up to date is always a good idea, of course.
>>
>> I'd prefer "in the loop" rather than "up to date". Heads up of the "hey,
>> we sent this to Core, do you have input?" variety feel more
>> "notification" rather than "collaboration".
>>
>> --Ben
>>
>> [1] Sure, Fortran supports multiple modules to be made per source. The
>> big step is from zero to one, not one to many.
>> _______________________________________________
>> SG21 mailing list
>> SG21_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
>> Link to this post: http://lists.isocpp.org/sg21/2023/11/5468.php
>
> _______________________________________________
> SG21 mailing list
> SG21_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> Link to this post: http://lists.isocpp.org/sg21/2023/11/5470.php