Date: Tue, 10 Mar 2020 15:46:51 +0000
Gaby,
It sounds like your solution, based on the linked PDF, is to avoid leading the users to think that these mechanical mappings will just work. If so, I think this is a good idea.
Best,
David P
From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Monday, March 9, 2020 at 5:19 PM
To: "Poliakoff, David Zoeller" <dzpolia_at_[hidden]v>, "sg15_at_[hidden]" <sg15_at_[hidden]>, Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Ben Boeckel via Modules <modules_at_[hidden]>, C++ Library Evolution Working Group <lib-ext_at_[hidden]>, Nathan Sidwell <nathan_at_[hidden]>
Subject: RE: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
* The person who sees a 20% speedup probably won’t notice, and certainly won’t tell their friends. The person who runs into a linker error or a compiler error absolutely will.
Absolutely!
* In addition to the view itself being logical, we’ll need documentation for how to port. If somebody thinks that “#include<vector>” can be replaced with “import std.vector”, are there places where that mapping isn’t true (will I import std.utility and std.functional? std.cassert sounds like it could be complicated).
In my approach to a coherent modular view of the standard library, there is no std.vector (I think that would be the wrong approach, the existing headers were optimized for something else; whatever it was, coherent and logical view wasn’t a priority), you just have std.core so you don’t need to have to import std.utility, std.functional, etc. And I wholeheartedly agree with you that having to do that sounds very complicated. There is no need to replicate that mistake.
See bullet 2 of http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0581r1.pdf
-- Gaby
From: Poliakoff, David Zoeller <dzpolia_at_sandia.gov>
Sent: Monday, March 9, 2020 3:52 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>; sg15_at_[hidden]; Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Ben Boeckel via Modules <modules_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
Subject: Re: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
Gabriel,
Absolutely, that’s a fair statement. I just hoped to drive home something from a “I’m begging people to move on to C++14” point of view.
The person who sees a 20% speedup probably won’t notice, and certainly won’t tell their friends. The person who runs into a linker error or a compiler error absolutely will.
In addition to the view itself being logical, we’ll need documentation for how to port. If somebody thinks that “#include<vector>” can be replaced with “import std.vector”, are there places where that mapping isn’t true (will I import std.utility and std.functional? std.cassert sounds like it could be complicated).
If mechanical mappings like this won’t work universally we need to make sure to avoid giving the impression that they will. If there is a clean mapping, we need to tell people what it is. The immediate potential complications I can think of would be
1. places where a header is named the same thing as a class (think “vector”), but that header includes more than just that class. “When I included <foo> it worked, importing std.foo now tells me that I haven’t defined ‘bar!’
2. Things like utility that aren’t named after a contained class
It sounds like (2) we’re solving by having these modules that just export a bunch (std.utility exports everything in utility). All of my solutions to (1) have definite drawbacks.
TL;DR: documentation is good
Best,
David P
From: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Date: Monday, March 9, 2020 at 4:37 PM
To: "sg15_at_[hidden]<mailto:sg15_at_[hidden]>" <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>, Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: "Poliakoff, David Zoeller" <dzpolia_at_[hidden]<mailto:dzpolia_at_[hidden]>>, Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>, C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>, Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: RE: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
To help such users, we must provide simple, coherent, and logical views of the standard library.
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Poliakoff, David Zoeller via SG15
Sent: Monday, March 9, 2020 7:59 AM
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]cpp.org>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Poliakoff, David Zoeller <dzpolia_at_[hidden]<mailto:dzpolia_at_[hidden]>>; Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>; C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>; Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: Re: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
Bryce,
I’m speaking more from the “naïve user” perspective here. The first time using
import std.vector
Behaves differently than
#include<vector>
We’ve added a decade to the time until many of the users I interact with will try modules again.
To me that equivalence is an extremely strong goal
Best,
David P
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> on behalf of Bryce Adelstein Lelbach aka wash via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Reply-To: "sg15_at_[hidden]cpp.org<mailto:sg15_at_[hidden]>" <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Date: Monday, March 9, 2020 at 5:26 AM
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Bryce Adelstein Lelbach aka wash <brycelelbach_at_gmail.com<mailto:brycelelbach_at_[hidden]>>, Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>, C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>, ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>, Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: [EXTERNAL] Re: [SG15] [isocpp-ext] Modularization of the standard library andABI stability
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?
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]g<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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2FP1453&data=02%7C01%7Cgdr%40microsoft.com%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338125633&sdata=hqX3DkXwbYzgKij8RFfEskaQWEI6%2Fm4Wj0XT9Ww5kvQ%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_[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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338135626&sdata=z1IfjMq8f797NHAjYV9ki5w8i5CKz6DPm68KiO62Pw8%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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338135626&sdata=V86%2B9kWlNw4MCVOUPipN%2BbPsg9ABT3azBXNdlbOFANQ%3D&reserved=0>
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]<mailto:Ext_at_[hidden]ocpp.org>
> 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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338145621&sdata=%2BaCHngwfcgbri%2B0L8qPw6%2FROsTJDKNcdhLjHT7jtZd8%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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338145621&sdata=jimUfyOMUWIOdAghAfYjAfJknQ8DKPOaeQPiEqxHH1Y%3D&reserved=0>
>
--
Nathan Sidwell
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]pp.org>
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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338155617&sdata=PHRL5lGeWhc1iq7EYmArNTK3gxItnQPMJWcwyQLR02s%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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338165608&sdata=dly7wMfznyUDgAA0HtQ8YKoMRJMaFhop0%2BHlOQIHCYI%3D&reserved=0>
It sounds like your solution, based on the linked PDF, is to avoid leading the users to think that these mechanical mappings will just work. If so, I think this is a good idea.
Best,
David P
From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Monday, March 9, 2020 at 5:19 PM
To: "Poliakoff, David Zoeller" <dzpolia_at_[hidden]v>, "sg15_at_[hidden]" <sg15_at_[hidden]>, Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Ben Boeckel via Modules <modules_at_[hidden]>, C++ Library Evolution Working Group <lib-ext_at_[hidden]>, Nathan Sidwell <nathan_at_[hidden]>
Subject: RE: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
* The person who sees a 20% speedup probably won’t notice, and certainly won’t tell their friends. The person who runs into a linker error or a compiler error absolutely will.
Absolutely!
* In addition to the view itself being logical, we’ll need documentation for how to port. If somebody thinks that “#include<vector>” can be replaced with “import std.vector”, are there places where that mapping isn’t true (will I import std.utility and std.functional? std.cassert sounds like it could be complicated).
In my approach to a coherent modular view of the standard library, there is no std.vector (I think that would be the wrong approach, the existing headers were optimized for something else; whatever it was, coherent and logical view wasn’t a priority), you just have std.core so you don’t need to have to import std.utility, std.functional, etc. And I wholeheartedly agree with you that having to do that sounds very complicated. There is no need to replicate that mistake.
See bullet 2 of http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0581r1.pdf
-- Gaby
From: Poliakoff, David Zoeller <dzpolia_at_sandia.gov>
Sent: Monday, March 9, 2020 3:52 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>; sg15_at_[hidden]; Evolution Working Group mailing list <ext_at_[hidden]>
Cc: Ben Boeckel via Modules <modules_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
Subject: Re: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
Gabriel,
Absolutely, that’s a fair statement. I just hoped to drive home something from a “I’m begging people to move on to C++14” point of view.
The person who sees a 20% speedup probably won’t notice, and certainly won’t tell their friends. The person who runs into a linker error or a compiler error absolutely will.
In addition to the view itself being logical, we’ll need documentation for how to port. If somebody thinks that “#include<vector>” can be replaced with “import std.vector”, are there places where that mapping isn’t true (will I import std.utility and std.functional? std.cassert sounds like it could be complicated).
If mechanical mappings like this won’t work universally we need to make sure to avoid giving the impression that they will. If there is a clean mapping, we need to tell people what it is. The immediate potential complications I can think of would be
1. places where a header is named the same thing as a class (think “vector”), but that header includes more than just that class. “When I included <foo> it worked, importing std.foo now tells me that I haven’t defined ‘bar!’
2. Things like utility that aren’t named after a contained class
It sounds like (2) we’re solving by having these modules that just export a bunch (std.utility exports everything in utility). All of my solutions to (1) have definite drawbacks.
TL;DR: documentation is good
Best,
David P
From: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Date: Monday, March 9, 2020 at 4:37 PM
To: "sg15_at_[hidden]<mailto:sg15_at_[hidden]>" <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>, Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: "Poliakoff, David Zoeller" <dzpolia_at_[hidden]<mailto:dzpolia_at_[hidden]>>, Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>, C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>, Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: RE: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
To help such users, we must provide simple, coherent, and logical views of the standard library.
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Poliakoff, David Zoeller via SG15
Sent: Monday, March 9, 2020 7:59 AM
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]cpp.org>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Poliakoff, David Zoeller <dzpolia_at_[hidden]<mailto:dzpolia_at_[hidden]>>; Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>; C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>; Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: Re: [SG15] [EXTERNAL] Re: [isocpp-ext] Modularization of the standard library andABI stability
Bryce,
I’m speaking more from the “naïve user” perspective here. The first time using
import std.vector
Behaves differently than
#include<vector>
We’ve added a decade to the time until many of the users I interact with will try modules again.
To me that equivalence is an extremely strong goal
Best,
David P
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> on behalf of Bryce Adelstein Lelbach aka wash via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Reply-To: "sg15_at_[hidden]cpp.org<mailto:sg15_at_[hidden]>" <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Date: Monday, March 9, 2020 at 5:26 AM
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Bryce Adelstein Lelbach aka wash <brycelelbach_at_gmail.com<mailto:brycelelbach_at_[hidden]>>, Ben Boeckel via Modules <modules_at_[hidden]<mailto:modules_at_[hidden]>>, C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>, ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>, Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
Subject: [EXTERNAL] Re: [SG15] [isocpp-ext] Modularization of the standard library andABI stability
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?
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]g<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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2FP1453&data=02%7C01%7Cgdr%40microsoft.com%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338125633&sdata=hqX3DkXwbYzgKij8RFfEskaQWEI6%2Fm4Wj0XT9Ww5kvQ%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_[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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338135626&sdata=z1IfjMq8f797NHAjYV9ki5w8i5CKz6DPm68KiO62Pw8%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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338135626&sdata=V86%2B9kWlNw4MCVOUPipN%2BbPsg9ABT3azBXNdlbOFANQ%3D&reserved=0>
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]<mailto:Ext_at_[hidden]ocpp.org>
> 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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338145621&sdata=%2BaCHngwfcgbri%2B0L8qPw6%2FROsTJDKNcdhLjHT7jtZd8%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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338145621&sdata=jimUfyOMUWIOdAghAfYjAfJknQ8DKPOaeQPiEqxHH1Y%3D&reserved=0>
>
--
Nathan Sidwell
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]pp.org>
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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338155617&sdata=PHRL5lGeWhc1iq7EYmArNTK3gxItnQPMJWcwyQLR02s%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%7Cb13857d6ec6a45c12cce08d7c47c804a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193911338165608&sdata=dly7wMfznyUDgAA0HtQ8YKoMRJMaFhop0%2BHlOQIHCYI%3D&reserved=0>
Received on 2020-03-10 10:49:40