In terms of user facing code I think not only do you get the same vector,
you must be able to write

#include <vector>
import std.vector

And not introduce ambiguity. We can't in practice require a forklift
upgrade to modules. It is certain that I will get vector definitions from
headers and modules. If they don't work properly together, modules get
banned.

On Mon, Mar 9, 2020, 07:58 Nathan Sidwell via Ext <ext_at_[hidden]>
wrote:

> 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
> _______________________________________________
> 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/12962.php
>