Was this requirement put on the header unit facility in general, or is it just new for standard library?
To recap. Today
#include <H>
import <H>;
doesn’t necessarily give you the same behavior as
import <H>;
#include <H>
for any “importable header”, in general.
This isn’t a rhetorical question, and I am not trying to equivoque – but merely trying to get us be coherent in our design, arguments, and rationale.
-- Gaby
From: Ext <ext-bounces@lists.isocpp.org> On Behalf Of
Steve Downey via Ext
Sent: Monday, March 9, 2020 5:32 AM
To: Evolution Working Group mailing list <ext@lists.isocpp.org>
Cc: Steve Downey <sdowney@gmail.com>; Ben Boeckel via Modules <modules@lists.isocpp.org>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>; C++ Library Evolution Working Group <lib-ext@lists.isocpp.org>; Nagy-Egri Máté Ferenc <nagy-egri.mate@wigner.mta.hu>;
Nathan Sidwell <nathan@acm.org>
Subject: Re: [isocpp-ext] [isocpp-modules] [SG15] Modularization of the standard library andABI stability
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@lists.isocpp.org> 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@lists.isocpp.org <mailto:modules@lists.isocpp.org>> 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@lists.isocpp.org <mailto:ext@lists.isocpp.org>> 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@lists.isocpp.org <mailto:ext@lists.isocpp.org>
> <mailto:ext@lists.isocpp.org <mailto:ext@lists.isocpp.org>>> 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@gmail.com
> <mailto:ville.voutilainen@gmail.com>
> <mailto:ville.voutilainen@gmail.com
> <mailto:ville.voutilainen@gmail.com>>>
> > wrote:
> >
> > On Mon, 9 Mar 2020 at 11:33, Bryce Adelstein Lelbach
> aka wash
> > <brycelelbach@gmail.com
> <mailto:brycelelbach@gmail.com> <mailto:brycelelbach@gmail.com
> <mailto:brycelelbach@gmail.com>>> 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@lists.isocpp.org <mailto:Ext@lists.isocpp.org>
> <mailto:Ext@lists.isocpp.org <mailto:Ext@lists.isocpp.org>>
> > 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@lists.isocpp.org <mailto:Ext@lists.isocpp.org>
> > 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@lists.isocpp.org <mailto:Ext@lists.isocpp.org>
> 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@lists.isocpp.org <mailto:Modules@lists.isocpp.org>
> 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@lists.isocpp.org
Subscription:
https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post:
http://lists.isocpp.org/ext/2020/03/12962.php