Date: Mon, 9 Mar 2020 16:34:00 -0700
> The person who sees a 20% speedup probably won’t notice
I think even just a 20% speedup will definitely be noticed and appreciated.
On Mon, Mar 9, 2020 at 3:52 PM Poliakoff, David Zoeller via SG15
<sg15_at_[hidden]> wrote:
>
> 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
>
>
>
> 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!’
> 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]>
> Date: Monday, March 9, 2020 at 4:37 PM
> To: "sg15_at_[hidden]" <sg15_at_[hidden]>, Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: "Poliakoff, David Zoeller" <dzpolia_at_[hidden]>, 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
>
>
>
> To help such users, we must provide simple, coherent, and logical views of the standard library.
>
>
>
> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Poliakoff, David Zoeller via SG15
> Sent: Monday, March 9, 2020 7:59 AM
> To: sg15_at_[hidden]; Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: Poliakoff, David Zoeller <dzpolia_at_[hidden]>; 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
>
>
>
> 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]> on behalf of Bryce Adelstein Lelbach aka wash via SG15 <sg15_at_[hidden]>
> Reply-To: "sg15_at_[hidden]" <sg15_at_[hidden]>
> Date: Monday, March 9, 2020 at 5:26 AM
> To: Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: Bryce Adelstein Lelbach aka wash <brycelelbach_at_[hidden]>, Ben Boeckel via Modules <modules_at_[hidden]>, C++ Library Evolution Working Group <lib-ext_at_[hidden]>, ISO C++ Tooling Study Group <sg15_at_[hidden]>, Nathan Sidwell <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]> 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]>> 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]>>
> > wrote:
> >
> > On Mon, 9 Mar 2020 at 11:33, Bryce Adelstein Lelbach aka wash
> > <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]>
> > 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]
> > 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]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2020/03/12955.php
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
I think even just a 20% speedup will definitely be noticed and appreciated.
On Mon, Mar 9, 2020 at 3:52 PM Poliakoff, David Zoeller via SG15
<sg15_at_[hidden]> wrote:
>
> 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
>
>
>
> 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!’
> 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]>
> Date: Monday, March 9, 2020 at 4:37 PM
> To: "sg15_at_[hidden]" <sg15_at_[hidden]>, Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: "Poliakoff, David Zoeller" <dzpolia_at_[hidden]>, 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
>
>
>
> To help such users, we must provide simple, coherent, and logical views of the standard library.
>
>
>
> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Poliakoff, David Zoeller via SG15
> Sent: Monday, March 9, 2020 7:59 AM
> To: sg15_at_[hidden]; Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: Poliakoff, David Zoeller <dzpolia_at_[hidden]>; 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
>
>
>
> 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]> on behalf of Bryce Adelstein Lelbach aka wash via SG15 <sg15_at_[hidden]>
> Reply-To: "sg15_at_[hidden]" <sg15_at_[hidden]>
> Date: Monday, March 9, 2020 at 5:26 AM
> To: Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: Bryce Adelstein Lelbach aka wash <brycelelbach_at_[hidden]>, Ben Boeckel via Modules <modules_at_[hidden]>, C++ Library Evolution Working Group <lib-ext_at_[hidden]>, ISO C++ Tooling Study Group <sg15_at_[hidden]>, Nathan Sidwell <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]> 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]>> 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]>>
> > wrote:
> >
> > On Mon, 9 Mar 2020 at 11:33, Bryce Adelstein Lelbach aka wash
> > <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]>
> > 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]
> > 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]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2020/03/12955.php
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
-- Bryce Adelstein Lelbach aka wash CUDA Core C++ Libraries Lead @ NVIDIA ISO C++ Library Evolution Incubator Chair ISO C++ Tooling Chair CppCon and C++Now Program Chair CUDA Convert and Reformed AVX Junkie Sleep is for the weak --
Received on 2020-03-09 18:37:13