Modularization of the libraries would also make a difference if/when we find a way to reuse BMIs between machines/builds. I understand that this is not the case now, but I think this is highly desired.
From: Modules <email@example.com> On Behalf Of
Bryce Adelstein Lelbach aka wash via Modules
Sent: Monday, March 9, 2020 2:29 AM
To: Nagy-Egri Máté Ferenc <firstname.lastname@example.org>
Cc: Bryce Adelstein Lelbach aka wash <email@example.com>; Ben Boeckel via Modules <firstname.lastname@example.org>; C++ Library Evolution Working Group <email@example.com>; ISO C++ Tooling Study Group <firstname.lastname@example.org>; Michael Spencer <email@example.com>; Evolution Working Group mailing list <firstname.lastname@example.org>
Subject: Re: [isocpp-modules] [SG15] [isocpp-ext] Modularization of the standard library andABI stability
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?
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 <email@example.com> 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>.
We call this include translation.
On Mon, Mar 9, 2020, 02:15 Bryce Adelstein Lelbach aka wash <firstname.lastname@example.org> 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 <email@example.com> 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
Elküldve: 2020. március 9., hétfő 5:48
Címzett: Michael Spencer
Másolatot kap: Bryce Adelstein Lelbach aka wash; Ben Boeckel via Modules; ISO C++ Tooling Study Group; C++ Library Evolution Working Group; Evolution Working Group mailing list
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 <firstname.lastname@example.org> wrote:
On Sun, Mar 8, 2020 at 2:01 PM Bryce Adelstein Lelbach aka wash via Ext <email@example.com> 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