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