On 3/9/20 7:27 AM, Corentin wrote:
>
>
> On Mon, 9 Mar 2020 at 12:20, Nathan Sidwell <nathan_at_[hidden]
> <mailto:nathan_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]>
> <mailto: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.
>
>
> That would be the correct solution indeed.


> Not the one WG21 wants:

That may be true, but it wasn't a requirement of the two goals Bryce
listed (they are silent about backwards compatibility). The goal that
led to 'it must be in the GM' should be explicitly listed.

Because, of course, if that goal is in fact just Bryce's recent question
of whether:
   import std.vector;
and
   #include <vector>
got you the same std::vector, then 'it must be in the GM' is not a
requirement.


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

-- 
Nathan Sidwell