On Mon, 9 Mar 2020 at 12:26, Bryce Adelstein Lelbach aka wash via Modules <
modules_at_[hidden]> wrote:

> If I understand correctly, you are suggesting that the reorganized
> modularized standard library could be ABI incompatible with the standard
> library you get with #includes.
>
> I have noticed an interesting property of all the "compromise" proposals
> for ABI evolution; they are all the moral equivalent of std2. I'm not
> making any judgements on whether that is good or bad.
>
> While I think your idea has merit, I think we should probably make it a
> design goal that:
>
> import std.vector
>
> and
>
> #include <vector>
>
> give you the same std::vector.
>
> Does anyone disagree with that goal?
>

That seems to be a strong requirement rather than a goal, but there are two
ways to gets there:

- The GB module fragments owns std::vector which is then declared and
defined in <vector>, the module just reexport its name.
- std::vector is declared and defined in a standard module which owns it
and <vector> import that module

The first solution is non-abi breaking the second solution is benefiting
from module ownership and fits the goal of "reorganizing"



>
>
>
> On Mon, Mar 9, 2020, 04:20 Nathan Sidwell via Ext <ext_at_[hidden]>
> wrote:
>
>> On 3/9/20 6:02 AM, Corentin via Ext wrote:
>> >
>> >
>> > On Mon, 9 Mar 2020 at 10:45, Bryce Adelstein Lelbach aka wash via Ext
>> > <ext_at_[hidden] <mailto:ext_at_[hidden]>> wrote:
>> >
>> > I want a scope on that reorganization.
>> >
>> >
>> > Again, the reorganization scope is limited by our willingness and
>> > ability to break abi
>>
>> > At the end of the day everything will still be owned by the global
>> > module fragment.
>>
>> You seem to be limiting your willingness to break ABI. You only need to
>> keep the GM ownership if you're unwilling to break (some subset of) the
>> ABI.
>>
>> Or, if you're breaking ABI, you don't need to preserve C++<N
>> compatibility. So you could implement the std headers as wrappers to
>> imports of named modules. No GM in sight.
>>
>>
>> >
>> >
>> > What problems do we want to solve? Possible answers:
>> >
>> > - Finer grained access to things, either in addition to or in place
>> > of coarse access (for example being able to just get function, not
>> > all of <functional>)
>> >
>> >
>> > very small modules FOR THE STANDARD LIBRARY provides little benefits
>> >
>> > - More logical access to things (tuple is in <tuple>, so clearly
>> > pair must be in <pair>... oh wait)
>> >
>> >
>> > I think that's more example or too small modules
>> >
>> > - Freestanding concerns (separate function from parts of
>> > <functional> that are complicated to freestandingifyl
>> >
>> >
>> > Having the free standing bits in a module seem useful
>> > Some precedent in rust. of course non trivial because of partially free
>> > standing things. I imagine that for the purposes of modules, having
>> > partially free standing classes considered free standing makes sense. I
>> > guess some exploration is needed there.
>> >
>> >
>> > On Mon, Mar 9, 2020, 02:39 Ville Voutilainen
>> > <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>>
>> > wrote:
>> >
>> > On Mon, 9 Mar 2020 at 11:33, Bryce Adelstein Lelbach aka wash
>> > <brycelelbach_at_[hidden] <mailto:brycelelbach_at_[hidden]>> wrote:
>> > >
>> > > I wrote a paper that in large part was a response to P0581,
>> > so yes, I've read it a few times.
>> > >
>> > > https://wg21.link/P1453
>> > >
>> > > It sounded like you were trying to make a point. Can you be
>> > clearer about what that point was?
>> >
>> > P0581 has some bits of rationale for providing named modules,
>> > not just
>> > transitioned headers.
>> > Reorganization seems to be one of them.
>> >
>> > _______________________________________________
>> > 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/12948.php
>> >
>> >
>> > _______________________________________________
>> > 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/12951.php
>> >
>>
>>
>> --
>> Nathan Sidwell
>> _______________________________________________
>> 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/12955.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/0826.php
>