> 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]> 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
> - No need to micro-manage target_precompile_headers
> - No compilation time hit for adding-removing modules (not headers)
> - Currently all throwaway / toy code pays the price
> - 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
> <sg15_at_[hidden]>
> *Elküldve: *2020. március 9., hétfő 5:48
> *Címzett: *Michael Spencer <bigcheesegs_at_[hidden]>
> *Másolatot kap: *Bryce Adelstein Lelbach aka wash <brycelelbach_at_[hidden]>;
> Ben Boeckel via Modules <modules_at_[hidden]>; ISO C++ Tooling Study
> Group <sg15_at_[hidden]>; C++ Library Evolution Working Group
> <lib-ext_at_[hidden]>; Evolution Working Group mailing list
> <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]> wrote:
>
>
>
>
>
> On Sun, Mar 8, 2020 at 2:01 PM Bryce Adelstein Lelbach aka wash via Ext <
> 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
>
>
>
>
>