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
>