On 3/9/20 7:35 AM, Corentin wrote:
>
>
> On Mon, 9 Mar 2020 at 12:26, Bryce Adelstein Lelbach aka wash via
> Modules <modules_at_[hidden] <mailto: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

I'm sorry, but you're equivocating. What is the difference between
'strong requirement' and 'goal'? Can we just start with:

goal: feature that must be provided

non-goal: feature that is orthogonal to the design ('don't cares')
non-goals only need to be specified if there is confusion about whether
a potential goal has been discussed (and determined to not be a goal),
or not discussed.

I like Bryce's formulation of the question, because it is user-facing
code. Code is precise. I think of the three possible options:
a) you get the same std::vector
b) you get different std::vectors
c) one of those formulations becomes ill-formed

#b & #c will cause incompatibilities between software units at the
source code level, with different failure modes

#c will also mean there's a source code barrier limiting the versions of
C++ that can be used. This particular case looks fairly invasive.

So, #a please.


, 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] <mailto: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]>
> <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.
>
>
> >
> >
> > 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
> _______________________________________________
> 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/12955.php
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden] <mailto: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
>

-- 
Nathan Sidwell