On Mon, 9 Mar 2020 at 10:29, Bryce Adelstein Lelbach aka wash via Ext <
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
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]> 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]> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
> Ext mailing list
> 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
>