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