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?



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
>