It is worse with <ccomplex> -- with the ā€˜cā€™ ā˜¹

 

From: Lib-Ext <lib-ext-bounces@lists.isocpp.org> On Behalf Of Billy O'Neal (VC LIBS) via Lib-Ext
Sent: Monday, March 9, 2020 2:33 PM
To: Ben Craig <ben.craig@ni.com>; lib-ext@lists.isocpp.org; Evolution Working Group mailing list <ext@lists.isocpp.org>
Cc: Billy O'Neal (VC LIBS) <bion@microsoft.com>; modules@lists.isocpp.org; Corentin <corentin.jabot@gmail.com>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>
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 )

 

Billy3


From: Ben Craig <ben.craig@ni.com>
Sent: Monday, March 9, 2020 02:27 PM
To: lib-ext@lists.isocpp.org <lib-ext@lists.isocpp.org>; Evolution Working Group mailing list <ext@lists.isocpp.org>
Cc: Corentin <corentin.jabot@gmail.com>; modules@lists.isocpp.org <modules@lists.isocpp.org>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>; Billy O'Neal (VC LIBS) <bion@microsoft.com>
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@lists.isocpp.org> On Behalf Of Corentin via Lib-Ext
Sent: Monday, March 9, 2020 3:12 PM
To: Evolution Working Group mailing list <ext@lists.isocpp.org>
Cc: Corentin <corentin.jabot@gmail.com>; modules@lists.isocpp.org; C++ Library Evolution Working Group <lib-ext@lists.isocpp.org>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>; Billy O'Neal (VC LIBS) <bion@microsoft.com>
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@lists.isocpp.org> 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@lists.isocpp.org> on behalf of JeanHeyd Meneide via Ext <ext@lists.isocpp.org>
Sent: Monday, March 9, 2020 12:55 PM
To: Evolution Working Group mailing list <ext@lists.isocpp.org>; modules@lists.isocpp.org <modules@lists.isocpp.org>; ISO C++ Tooling Study Group <sg15@lists.isocpp.org>; C++ Library Evolution Working Group <lib-ext@lists.isocpp.org>
Cc: JeanHeyd Meneide <phdofthehouse@gmail.com>
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@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

     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@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
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

_______________________________________________
Ext mailing list
Ext@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2020/03/12971.php