On 3/9/20 5:56 AM, Corentin via Modules wrote:
>
>
> On Mon, 9 Mar 2020 at 10:29, Bryce Adelstein Lelbach aka wash via Ext
> <ext_at_[hidden] <mailto:ext_at_[hidden]>> wrote:
>
> I'm going to put forward an argument for why the committee wants a
> modularized standard library:
>
> 0) Modernization through example: we get the benefit of modules
> via importable headers in C++20 with standard library includes,
> but we don't just want the benefits, we also want to promote the
> new programming model. Even if #include <thing> and import <thing>
> work and are no worse than import std.thing we want import
> std.thing because that is the modern idiom.
>
> 1) Reorganization: this is actually less about modularization
> (which we've already done in C++20 to the extent that we can for
> existing implementations) and more about reorganizing/refactoring
> the user-facing componentization of the standard library.
>
> Can we all agree these are the goals that we want?
>
>
>
> I don't think modularizing the library the way Michael proposes is a
> good example (which is different to say that it wouldn't be a good
> solution for the STL).
> It doesn't actually modularize anything
>
>
> An alternative (which is only non abi breaking in the weak model) is
> to properly reorganize the standard library in modules and existing
> headers can be implemented in terms of import statements

I'm curious how that would work for existing code bases that will need
to build C++20 code with modules support disabled (e.g., because their
build system isn't equipped to build the necessary modules or because
they depend on macro interactions with existing implementation headers).

Tom.

> That second way is the only way to reorganize.
>
>
> P.S. Remember that we voted to prioritize this work in P0592. So
> we ought to have a clear idea of what we actually want.
>
> On Mon, Mar 9, 2020, 02:19 Bryce Adelstein Lelbach aka wash
> <brycelelbach_at_[hidden] <mailto:brycelelbach_at_[hidden]>> wrote:
>
> To further clarify:
>
> > just by changing #include to import
>
> In C++20 your implementation is allowed to replace your
> #includes of C++ standard library headers with imports,
> excluding a few <cstuff> headers that are fundamentally
> textual like <cassert>.
>
> http://eel.is/c++draft/cpp.include#7
>
> We call this include translation.
>
> On Mon, Mar 9, 2020, 02:15 Bryce Adelstein Lelbach aka wash
> <brycelelbach_at_[hidden] <mailto:brycelelbach_at_[hidden]>> wrote:
>
> > From a users perspective, having STL modules would speed
> up compilation times immensely
>
> As I said in my email, standard library headers are
> already importable in C++20. So your implementation can
> already replace #include <vector> with import <vector>;
>
> I don't know that we can really do that much more than
> that; we could have an import std.vector, but it sounds
> like (0) std::vector would have to remain in the global
> module and (1) standard library implementation details
> would probably have to remain in the global module as well.
>
> TL;DR the use case you described is already covered in C++20.
>
> On Mon, Mar 9, 2020, 02:11 Nagy-Egri Máté Ferenc
> <nagy-egri.mate_at_[hidden]
> <mailto:nagy-egri.mate_at_[hidden]>> wrote:
>
> From a users perspective, having STL modules would
> speed up compilation times immensely. The current
> problem is that if we want to improve compile speeds,
> we pre-compile the STL parts we use. We either
> pre-compile everything to save programmer time and not
> care what parts we’re using (PCH becomes HUGE), or we
> selectively manage (tedious to update CMakeLists.txt
> for every #include we add). Also, if the PCH changes,
> we take a large hit for updating it.
>
> If the group seems decided that the definition /
> implementation of STL entities would need to be
> shuffled around anyway for proper modular design, I’d
> argue that creating a module for every STL header
> still has its benefit:
>
> * Build systems would pick up module dependence
> automatically, just like with headers
> o No need to micro-manage target_precompile_headers
> * No compilation time hit for adding-removing
> modules (not headers)
> o Currently all throwaway / toy code pays the price
> o PCH gets recompiled for every CMake config change
>
> If ODR stands with headers, it should do too with
> modules, given every header is its own module. (It
> would likely even stand when mixing modules and
> headers: for eg. import a std module and include a
> boost header after, which in turn includes std
> headers.) Not nice, but just by changing #include to
> import, compile times would improve to always using
> just the right amount of PCH. That alone is a great deal.
>
> Would this be worth the effort?
>
> *Feladó: *Bryce Adelstein Lelbach aka wash via SG15
> <mailto:sg15_at_[hidden]>
> *Elküldve: *2020. március 9., hétfő 5:48
> *Címzett: *Michael Spencer <mailto:bigcheesegs_at_[hidden]>
> *Másolatot kap: *Bryce Adelstein Lelbach aka wash
> <mailto:brycelelbach_at_[hidden]>; Ben Boeckel via
> Modules <mailto:modules_at_[hidden]>; ISO C++
> Tooling Study Group <mailto:sg15_at_[hidden]>;
> C++ Library Evolution Working Group
> <mailto:lib-ext_at_[hidden]>; Evolution Working
> Group mailing list <mailto:ext_at_[hidden]>
> *Tárgy: *Re: [SG15] [isocpp-ext] Modularization of the
> standard library andABI stability
>
> What is the benefit of modularizing the standard
> library in C++23, given that standard library headers
> (modulo a few like <cassert>) are already importable?
>
> On Sun, Mar 8, 2020, 21:31 Michael Spencer
> <bigcheesegs_at_[hidden] <mailto:bigcheesegs_at_[hidden]>>
> wrote:
>
> On Sun, Mar 8, 2020 at 2:01 PM Bryce Adelstein
> Lelbach aka wash via Ext <ext_at_[hidden]
> <mailto:ext_at_[hidden]>> wrote:
>
> Do we have any ABI stability concerns
> regarding modularizing the standard library?
> Certainly for strong module ownership
> implementations, this is a concern, but for
> weak module ownership implementations it may
> be a concern too, because the mangling of
> internal implementation details with module
> linkage would change.
>
> Can implementations overcome this with special
> hacks for the standard library that preserve
> the old mangled names?
>
> I don't expect stdlibs to move off of headers in
> the foreseeable future (in order to support
> pre-modules compilers and build systems). Given
> this I expect standard library entities to remain
> the in global module, and thus the named module
> they are exported from to be irrelevant. If
> someone writes a new C++20+ only stdlib then they
> will have a different ABI anyway, but there would
> then be potential ABI breakage from moving an
> entity. However, it is not observable which module
> an entity is from, so it's quite easy to work
> around any ABI changes that would occur due to
> moving where an entity is. I seriously doubt we
> would remove a declaration from a module without
> removing the declaration entirely though, which is
> the only way you would end up needing to change
> which module owns it.
>
>
> - Michael Spencer
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden] <mailto:Ext_at_[hidden]>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2020/03/12944.php
>
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2020/03/0820.php