Date: Mon, 9 Mar 2020 21:49:08 +0000
> Modules are supposed to avoid the need to ask that question (and the need for forwarding for the sake of build speed.)
Perhaps, but P0581 takes steps to try to remove the dependency that complex has on iostreams.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0581r1.pdf
From: Corentin <corentin.jabot_at_[hidden]>
Sent: Monday, March 9, 2020 4:47 PM
To: Ben Craig <ben.craig_at_[hidden]>
Cc: lib-ext_at_[hidden]; Evolution Working Group mailing list <ext_at_[hidden]>; modules_at_[hidden]; ISO C++ Tooling Study Group <sg15_at_[hidden]>; Billy O'Neal (VC LIBS) <bion_at_[hidden]>
Subject: [EXTERNAL] Re: Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability
On Mon, 9 Mar 2020 at 22:27, Ben Craig <ben.craig_at_ni.com<mailto:ben.craig_at_[hidden]>> wrote:
Note that hidden friending could have negative modularity effects. Do you really want std::complex to need to pull in iosfwd first before hidden friending op<< ? This would also mean that the module that has std::complex has to pull in the module that has iostreams.
Modules are supposed to avoid the need to ask that question (and the need for forwarding for the sake of build speed.)
From: Lib-Ext <lib-ext-bounces_at_[hidden]<mailto:lib-ext-bounces_at_[hidden]>> On Behalf Of Corentin via Lib-Ext
Sent: Monday, March 9, 2020 3:12 PM
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>>; 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]>>; Billy O'Neal (VC LIBS) <bion_at_[hidden]<mailto:bion_at_[hidden]>>
Subject: [EXTERNAL] Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability
On Mon, 9 Mar 2020 at 21:08, Billy O'Neal (VC LIBS) via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Most of those overload set effects appear unintentional and we should look at "hidden friend"-ing all of them.
+1
________________________________
From: Ext <ext-bounces_at_[hidden]<mailto:ext-bounces_at_[hidden]>> on behalf of JeanHeyd Meneide via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Sent: Monday, March 9, 2020 12:55 PM
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>; modules_at_[hidden]<mailto:modules_at_[hidden]> <modules_at_[hidden]<mailto:modules_at_[hidden]>>; ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>; C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>
Cc: JeanHeyd Meneide <phdofthehouse_at_[hidden]<mailto:phdofthehouse_at_[hidden]>>
Subject: Re: [isocpp-ext] [SG15] Modularization of the standard library andABI stability
Dear Tooling/EWG/LEWG,
On Mon, Mar 9, 2020 at 3:36 PM Steve Downey via Ext
<ext_at_[hidden]ocpp.org<mailto:ext_at_[hidden]>> wrote:
>
> In particular, I'd like to see, and measure, the costs of having large overload sets present before committing to a module the size of `std` as opposed to smaller ones where I can exclude parts I am uninterested in.
>
I echo Steve's concern here. "import std;" can possibly lead to a
lot of suboptimal overload resolution. For example, clang-format
accidentally brought in extra overload sets related to std::locale and
tanked someone's performance just because of the order of includes:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravisdowns.github.io%2Fblog%2F2019%2F11%2F19%2Ftoupper.html&data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&sdata=vi2SJdjeiTYX0kx3CNadLbuhHyWstxIVn8rATyXfW4Y%3D&reserved=0<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftravisdowns.github.io*2Fblog*2F2019*2F11*2F19*2Ftoupper.html&data=02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630&sdata=vi2SJdjeiTYX0kx3CNadLbuhHyWstxIVn8rATyXfW4Y*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPGtOt_IU$>
C++ is incredibly sensitive to what entities are available. Since
we do not have a selection syntax (e.g., import std with { vector,
string, find_if, ... }), then our only way to control visibility --
and thus, overload resolution -- is with carefully crafted module
buckets. While there is probably no harm in having "import std;" exist
in general, we should be mindful of the problems that already exist
with "expose all the functions and types, ever" for existing and new
code. Therefore, I think both "import std;" as well as more targeted
library buckets should be considered.
Sincerely,
JeanHeyd
_______________________________________________
Ext mailing list
Ext_at_lists.isocpp.org<mailto:Ext_at_[hidden]>
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&sdata=gCqfTZuDmKbEJj08Iq%2FJDQq9rEcgpvjOCXQ%2BNTLd9LI%3D&reserved=0<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Flists.isocpp.org*2Fmailman*2Flistinfo.cgi*2Fext&data=02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630&sdata=gCqfTZuDmKbEJj08Iq*2FJDQq9rEcgpvjOCXQ*2BNTLd9LI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPOGdmVlF$>
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12970.php&data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&sdata=oGZkMKrYm3I2dzXq5%2B5G8QoWSb7q1GcgfnEiOofVJLs%3D&reserved=0<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=http*3A*2F*2Flists.isocpp.org*2Fext*2F2020*2F03*2F12970.php&data=02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630&sdata=oGZkMKrYm3I2dzXq5*2B5G8QoWSb7q1GcgfnEiOofVJLs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPNoKW9ev$>
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/ext__;!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPFqioVDs$>
Link to this post: http://lists.isocpp.org/ext/2020/03/12971.php<https://urldefense.com/v3/__http:/lists.isocpp.org/ext/2020/03/12971.php__;!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPM2z7SgF$>
Perhaps, but P0581 takes steps to try to remove the dependency that complex has on iostreams.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0581r1.pdf
From: Corentin <corentin.jabot_at_[hidden]>
Sent: Monday, March 9, 2020 4:47 PM
To: Ben Craig <ben.craig_at_[hidden]>
Cc: lib-ext_at_[hidden]; Evolution Working Group mailing list <ext_at_[hidden]>; modules_at_[hidden]; ISO C++ Tooling Study Group <sg15_at_[hidden]>; Billy O'Neal (VC LIBS) <bion_at_[hidden]>
Subject: [EXTERNAL] Re: Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability
On Mon, 9 Mar 2020 at 22:27, Ben Craig <ben.craig_at_ni.com<mailto:ben.craig_at_[hidden]>> wrote:
Note that hidden friending could have negative modularity effects. Do you really want std::complex to need to pull in iosfwd first before hidden friending op<< ? This would also mean that the module that has std::complex has to pull in the module that has iostreams.
Modules are supposed to avoid the need to ask that question (and the need for forwarding for the sake of build speed.)
From: Lib-Ext <lib-ext-bounces_at_[hidden]<mailto:lib-ext-bounces_at_[hidden]>> On Behalf Of Corentin via Lib-Ext
Sent: Monday, March 9, 2020 3:12 PM
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>>; 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]>>; Billy O'Neal (VC LIBS) <bion_at_[hidden]<mailto:bion_at_[hidden]>>
Subject: [EXTERNAL] Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability
On Mon, 9 Mar 2020 at 21:08, Billy O'Neal (VC LIBS) via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Most of those overload set effects appear unintentional and we should look at "hidden friend"-ing all of them.
+1
________________________________
From: Ext <ext-bounces_at_[hidden]<mailto:ext-bounces_at_[hidden]>> on behalf of JeanHeyd Meneide via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Sent: Monday, March 9, 2020 12:55 PM
To: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>; modules_at_[hidden]<mailto:modules_at_[hidden]> <modules_at_[hidden]<mailto:modules_at_[hidden]>>; ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>; C++ Library Evolution Working Group <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>
Cc: JeanHeyd Meneide <phdofthehouse_at_[hidden]<mailto:phdofthehouse_at_[hidden]>>
Subject: Re: [isocpp-ext] [SG15] Modularization of the standard library andABI stability
Dear Tooling/EWG/LEWG,
On Mon, Mar 9, 2020 at 3:36 PM Steve Downey via Ext
<ext_at_[hidden]ocpp.org<mailto:ext_at_[hidden]>> wrote:
>
> In particular, I'd like to see, and measure, the costs of having large overload sets present before committing to a module the size of `std` as opposed to smaller ones where I can exclude parts I am uninterested in.
>
I echo Steve's concern here. "import std;" can possibly lead to a
lot of suboptimal overload resolution. For example, clang-format
accidentally brought in extra overload sets related to std::locale and
tanked someone's performance just because of the order of includes:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravisdowns.github.io%2Fblog%2F2019%2F11%2F19%2Ftoupper.html&data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&sdata=vi2SJdjeiTYX0kx3CNadLbuhHyWstxIVn8rATyXfW4Y%3D&reserved=0<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftravisdowns.github.io*2Fblog*2F2019*2F11*2F19*2Ftoupper.html&data=02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630&sdata=vi2SJdjeiTYX0kx3CNadLbuhHyWstxIVn8rATyXfW4Y*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPGtOt_IU$>
C++ is incredibly sensitive to what entities are available. Since
we do not have a selection syntax (e.g., import std with { vector,
string, find_if, ... }), then our only way to control visibility --
and thus, overload resolution -- is with carefully crafted module
buckets. While there is probably no harm in having "import std;" exist
in general, we should be mindful of the problems that already exist
with "expose all the functions and types, ever" for existing and new
code. Therefore, I think both "import std;" as well as more targeted
library buckets should be considered.
Sincerely,
JeanHeyd
_______________________________________________
Ext mailing list
Ext_at_lists.isocpp.org<mailto:Ext_at_[hidden]>
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&sdata=gCqfTZuDmKbEJj08Iq%2FJDQq9rEcgpvjOCXQ%2BNTLd9LI%3D&reserved=0<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Flists.isocpp.org*2Fmailman*2Flistinfo.cgi*2Fext&data=02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630&sdata=gCqfTZuDmKbEJj08Iq*2FJDQq9rEcgpvjOCXQ*2BNTLd9LI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPOGdmVlF$>
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12970.php&data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&sdata=oGZkMKrYm3I2dzXq5%2B5G8QoWSb7q1GcgfnEiOofVJLs%3D&reserved=0<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=http*3A*2F*2Flists.isocpp.org*2Fext*2F2020*2F03*2F12970.php&data=02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630&sdata=oGZkMKrYm3I2dzXq5*2B5G8QoWSb7q1GcgfnEiOofVJLs*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPNoKW9ev$>
_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/ext__;!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPFqioVDs$>
Link to this post: http://lists.isocpp.org/ext/2020/03/12971.php<https://urldefense.com/v3/__http:/lists.isocpp.org/ext/2020/03/12971.php__;!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPM2z7SgF$>
Received on 2020-03-09 16:52:11