Date: Mon, 9 Mar 2020 22:34:37 +0000
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_at_[hidden]socpp.org> On Behalf Of Steve Downey via Ext
Sent: Monday, March 9, 2020 5:32 AM
To: Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Steve Downey <sdowney_at_[hidden]>; Ben Boeckel via Modules <modules_at_[hidden]>; ISO C++ Tooling Study Group <sg15_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]>; Nagy-Egri Máté Ferenc <nagy-egri.mate_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
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_at_[hidden]<mailto: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_lists.isocpp.org> <mailto: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]g> <mailto: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]>>
> <mailto:ext_at_lists.isocpp.org<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].com<mailto:ville.voutilainen_at_[hidden]>
> <mailto:ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>>
> <mailto: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]>> <mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2FP1453&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329517266&sdata=a10YxpcdGdDeZhkZDNn%2FP0hhCLg2VyvVrkhYFfZ%2BIRI%3D&reserved=0>
> > >
> > > 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_lists.isocpp.org<mailto:Ext_at_[hidden]> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>
> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>>
> > Subscription:
> https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329517266&sdata=SWVE%2FsqL%2FCRqqTeKwyadgLqcOkw5GlWwRrWP415%2B65U%3D&reserved=0>
> > Link to this post:
> http://lists.isocpp.org/ext/2020/03/12948.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12948.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329527257&sdata=UsVpN%2FHGed%2F0y2V3IfZ8aNXDfvQUwi9yaFfSxBcozyI%3D&reserved=0>
> >
> >
> > _______________________________________________
> > Ext mailing list
> > Ext_at_[hidden]ocpp.org<mailto:Ext_at_[hidden]> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329527257&sdata=jZU%2Bl%2BidivsxDWNTBGAiFQAvDR6SVvY5GRuNYWRRN2U%3D&reserved=0>
> > Link to this post: http://lists.isocpp.org/ext/2020/03/12951.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12951.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329537255&sdata=CJEeQabpbk37JKUojMF%2FJlnva2wHMiznvlKNySXqFMM%3D&reserved=0>
> >
>
>
> --
> Nathan Sidwell
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]<mailto:Ext_at_[hidden]cpp.org> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329537255&sdata=8MPwzw5%2FMZUS4u6SqH9mTGRAlP3A0jBGE%2FBzsVdQ9ts%3D&reserved=0>
> Link to this post: http://lists.isocpp.org/ext/2020/03/12955.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12955.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329547253&sdata=5sYPxWhTUlMHM45B%2BBfF%2BLzOQUpC9MVcukVDXFC%2FuXg%3D&reserved=0>
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]g<mailto:Modules_at_[hidden]> <mailto:Modules_at_[hidden]<mailto:Modules_at_[hidden]>>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/modules<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329547253&sdata=1Dzxt1yN3augNe6l2kVHJkN02JZ0jCZTOEZcZmajTuQ%3D&reserved=0>
> Link to this post: http://lists.isocpp.org/modules/2020/03/0826.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2020%2F03%2F0826.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329557251&sdata=%2FEMTJ3xqdheA6n2X5vyBbOqprxxxvPvvqC5GxoWMBCU%3D&reserved=0>
>
--
Nathan Sidwell
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]rg>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329557251&sdata=awxhACW0u3eZX0cvYvdupE%2FHMPN%2B6rv4GlFkJizBIOQ%3D&reserved=0>
Link to this post: http://lists.isocpp.org/ext/2020/03/12962.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12962.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329567242&sdata=EDw%2BUr4PW2rMlCqwxrtr3l09HH9%2FOKM3JpqVhireQ5M%3D&reserved=0>
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_at_[hidden]socpp.org> On Behalf Of Steve Downey via Ext
Sent: Monday, March 9, 2020 5:32 AM
To: Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Steve Downey <sdowney_at_[hidden]>; Ben Boeckel via Modules <modules_at_[hidden]>; ISO C++ Tooling Study Group <sg15_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]>; Nagy-Egri Máté Ferenc <nagy-egri.mate_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
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_at_[hidden]<mailto: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_lists.isocpp.org> <mailto: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]g> <mailto: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]>>
> <mailto:ext_at_lists.isocpp.org<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].com<mailto:ville.voutilainen_at_[hidden]>
> <mailto:ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>>
> <mailto: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]>> <mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2FP1453&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329517266&sdata=a10YxpcdGdDeZhkZDNn%2FP0hhCLg2VyvVrkhYFfZ%2BIRI%3D&reserved=0>
> > >
> > > 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_lists.isocpp.org<mailto:Ext_at_[hidden]> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>
> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>>
> > Subscription:
> https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329517266&sdata=SWVE%2FsqL%2FCRqqTeKwyadgLqcOkw5GlWwRrWP415%2B65U%3D&reserved=0>
> > Link to this post:
> http://lists.isocpp.org/ext/2020/03/12948.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12948.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329527257&sdata=UsVpN%2FHGed%2F0y2V3IfZ8aNXDfvQUwi9yaFfSxBcozyI%3D&reserved=0>
> >
> >
> > _______________________________________________
> > Ext mailing list
> > Ext_at_[hidden]ocpp.org<mailto:Ext_at_[hidden]> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329527257&sdata=jZU%2Bl%2BidivsxDWNTBGAiFQAvDR6SVvY5GRuNYWRRN2U%3D&reserved=0>
> > Link to this post: http://lists.isocpp.org/ext/2020/03/12951.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12951.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329537255&sdata=CJEeQabpbk37JKUojMF%2FJlnva2wHMiznvlKNySXqFMM%3D&reserved=0>
> >
>
>
> --
> Nathan Sidwell
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]<mailto:Ext_at_[hidden]cpp.org> <mailto:Ext_at_[hidden]<mailto:Ext_at_[hidden]>>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329537255&sdata=8MPwzw5%2FMZUS4u6SqH9mTGRAlP3A0jBGE%2FBzsVdQ9ts%3D&reserved=0>
> Link to this post: http://lists.isocpp.org/ext/2020/03/12955.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12955.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329547253&sdata=5sYPxWhTUlMHM45B%2BBfF%2BLzOQUpC9MVcukVDXFC%2FuXg%3D&reserved=0>
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]g<mailto:Modules_at_[hidden]> <mailto:Modules_at_[hidden]<mailto:Modules_at_[hidden]>>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/modules<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329547253&sdata=1Dzxt1yN3augNe6l2kVHJkN02JZ0jCZTOEZcZmajTuQ%3D&reserved=0>
> Link to this post: http://lists.isocpp.org/modules/2020/03/0826.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2020%2F03%2F0826.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329557251&sdata=%2FEMTJ3xqdheA6n2X5vyBbOqprxxxvPvvqC5GxoWMBCU%3D&reserved=0>
>
--
Nathan Sidwell
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]rg>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329557251&sdata=awxhACW0u3eZX0cvYvdupE%2FHMPN%2B6rv4GlFkJizBIOQ%3D&reserved=0>
Link to this post: http://lists.isocpp.org/ext/2020/03/12962.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12962.php&data=02%7C01%7Cgdr%40microsoft.com%7Ce55e94b20ddc4f92d74808d7c425e443%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193539329567242&sdata=EDw%2BUr4PW2rMlCqwxrtr3l09HH9%2FOKM3JpqVhireQ5M%3D&reserved=0>
Received on 2020-03-09 17:37:24