On Mon, 9 Mar 2020 at 22:27, Ben Craig <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]> *On Behalf Of *Corentin
> via Lib-Ext
> *Sent:* Monday, March 9, 2020 3:12 PM
> *To:* Evolution Working Group mailing list <ext_at_[hidden]>
> *Cc:* Corentin <corentin.jabot_at_[hidden]>; modules_at_[hidden]; C++
> Library Evolution Working Group <lib-ext_at_[hidden]>; ISO C++
> Tooling Study Group <sg15_at_[hidden]>; Billy O'Neal (VC LIBS) <
> 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]> 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]> on behalf of JeanHeyd Meneide
> via Ext <ext_at_[hidden]>
> *Sent:* Monday, March 9, 2020 12:55 PM
> *To:* Evolution Working Group mailing list <ext_at_[hidden]>;
> modules_at_[hidden] <modules_at_[hidden]>; ISO C++ Tooling
> Study Group <sg15_at_[hidden]>; C++ Library Evolution Working Group <
> lib-ext_at_[hidden]>
> *Cc:* JeanHeyd Meneide <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]> 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://urldefense.com/v3/__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__;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_[hidden]
> 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://urldefense.com/v3/__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__;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&amp;data=02%7C01%7Cbion%40microsoft.com%7C4516b16941c64e934cc708d7c463cc0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637193805220385630&amp;sdata=oGZkMKrYm3I2dzXq5%2B5G8QoWSb7q1GcgfnEiOofVJLs%3D&amp;reserved=0
> <https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSU!!FbZ0ZwI3Qg!4cToOe-ahsjUyy7hdj_ATGUOQXT4L_6cjKyfkfkPY9NSdj8SXL5lPNoKW9ev$>
>
> _______________________________________________
> Ext mailing list
> 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$>
>
>