Yes. My point was compared to the C header <complex.h> that we were supposed to be compatible with. It doesn’t drag IO stream in any form.

From: Billy O'Neal (VC LIBS) <bion_at_[hidden]>
Sent: Monday, March 9, 2020 3:58 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>; lib-ext_at_lists.isocpp.org; Ben Craig <ben.craig_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]>
Cc: modules_at_[hidden]; Corentin <corentin.jabot_at_[hidden]>; ISO C++ Tooling Study Group <sg15_at_[hidden]>
Subject: Re: Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability

<ccomplex> includes <complex.h> as per http://eel.is/c++draft/depr.c.headers.other<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdepr.c.headers.other&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683660305&sdata=HHi0wqteQGX1UHq7i3Q2GXsrhlB4MJUykVih7nEkQtI%3D&reserved=0> , and <complex.h> includes <complex> as per http://eel.is/c++draft/depr.complex.h.syn<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fdepr.complex.h.syn&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683670299&sdata=v8hxKHW47Qgx7wvLz3RKwFWO2In25cqi%2FyLR6Wx20kw%3D&reserved=0>, so they have identical contents.

Billy3
________________________________
From: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Sent: Monday, March 9, 2020 03:39 PM
To: lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]cpp.org> <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>; Ben Craig <ben.craig_at_[hidden]<mailto:ben.craig_at_[hidden]>>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Billy O'Neal (VC LIBS) <bion_at_[hidden]<mailto:bion_at_[hidden]>>; modules_at_[hidden]<mailto:modules_at_[hidden]> <modules_at_[hidden]<mailto:modules_at_[hidden]>>; Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>>; ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Subject: RE: Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability


It is worse with <ccomplex> -- with the ‘c’ ☹



From: Lib-Ext <lib-ext-bounces_at_[hidden]<mailto:lib-ext-bounces_at_[hidden]>> On Behalf Of Billy O'Neal (VC LIBS) via Lib-Ext
Sent: Monday, March 9, 2020 2:33 PM
To: Ben Craig <ben.craig_at_[hidden]<mailto:ben.craig_at_[hidden]>>; lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Cc: Billy O'Neal (VC LIBS) <bion_at_[hidden]<mailto:bion_at_[hidden]>>; modules_at_[hidden]<mailto:modules_at_[hidden]>; Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>>; ISO C++ Tooling Study Group <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>
Subject: Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability



>Do you really want std::complex to need to pull in iosfwd first before hidden friending op<< ?



The status quo is that `<complex>` needs to pull in `<sstream>` to implement that `operator<<` so there's no change there. ( http://eel.is/c++draft/complex.numbers#complex.ops-14<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcomplex.numbers%23complex.ops-14&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683670299&sdata=7CDyGXO01NTzA4DVQFfg3Z8UqGJTO3iQyyJ%2FV74pim0%3D&reserved=0> )



Billy3

________________________________

From: Ben Craig <ben.craig_at_[hidden]<mailto:ben.craig_at_[hidden]>>
Sent: Monday, March 9, 2020 02:27 PM
To: lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden].org> <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>>; 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]> <modules_at_[hidden]<mailto:modules_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: RE: Re: [isocpp-lib-ext] [isocpp-ext] [SG15] Modularization of the standard library andABI stability



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.



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]g<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]<mailto:ext_at_lists.isocpp.org>> 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&amp;data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&amp;sdata=vi2SJdjeiTYX0kx3CNadLbuhHyWstxIVn8rATyXfW4Y%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Ftravisdowns.github.io*2Fblog*2F2019*2F11*2F19*2Ftoupper.html%26data%3D02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630%26sdata%3Dvi2SJdjeiTYX0kx3CNadLbuhHyWstxIVn8rATyXfW4Y*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPGtOt_IU%24&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683680296&sdata=qPjrg%2FnYP2ZgIrCGol2bwhXXpZc%2Bb1jXDYcmVox7RH4%3D&reserved=0>

     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_[hidden]<mailto:Ext_at_lists.isocpp.org>
Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&amp;data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&amp;sdata=gCqfTZuDmKbEJj08Iq%2FJDQq9rEcgpvjOCXQ%2BNTLd9LI%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Flists.isocpp.org*2Fmailman*2Flistinfo.cgi*2Fext%26data%3D02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630%26sdata%3DgCqfTZuDmKbEJj08Iq*2FJDQq9rEcgpvjOCXQ*2BNTLd9LI*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPOGdmVlF%24&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683680296&sdata=Uby04F5ZL5B%2Fx8Fkcgu7yh2vCFnGg3j30eBe3wu57vc%3D&reserved=0>
Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12970.php&amp;data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&amp;sdata=oGZkMKrYm3I2dzXq5%2B5G8QoWSb7q1GcgfnEiOofVJLs%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttp*3A*2F*2Flists.isocpp.org*2Fext*2F2020*2F03*2F12970.php%26data%3D02*7C01*7Cbion*40microsoft.com*7C4516b16941c64e934cc708d7c463cc0a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637193805220385630%26sdata%3DoGZkMKrYm3I2dzXq5*2B5G8QoWSb7q1GcgfnEiOofVJLs*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPNoKW9ev%24&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683690290&sdata=ZMqD4cRV48t1fFjTcSr19lmuQ%2BuY15A33szzEZ3fEA8%3D&reserved=0>

_______________________________________________
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%2Furldefense.com%2Fv3%2F__https%3A%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext__%3B!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPFqioVDs%24&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683700282&sdata=Vugojnb59NtVIKtrEpDSWp3ZA0QtoxpPoNdi3BdWxag%3D&reserved=0>
Link to this post: http://lists.isocpp.org/ext/2020/03/12971.php<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Flists.isocpp.org%2Fext%2F2020%2F03%2F12971.php__%3B!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPM2z7SgF%24&data=02%7C01%7Cgdr%40microsoft.com%7Ce647ac37f3ca47fc01f508d7c47d491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193914683700282&sdata=AYjA7rBYDEzD1wt6KIL42nEsQJz5JT2QEoQm7XNOOA0%3D&reserved=0>