On Mon, Nov 13, 2023, 17:19 Joshua Berne <berne_at_[hidden]> wrote:

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

I think it should at least be discussed within SG21 as SG15 suggested:
 https://wiki.edg.com/bin/view/Wg21kona2023/SG15P2947.


> 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
>