Date: Mon, 25 Apr 2022 21:49:25 +0000
* I had concerns about adoption of modules (and dialect splits) 5 years ago and I didn't consider it premature then :)
Indeed đ
5 years ago, there was only one implementation of the proposal. 5 years later, we still have only one production-ready implementation of the feature; two are in-flight.
I very much want to discourage us from thinking that a âquickâ path to adoption passes through absorbing the complexity and anarchy of existing header files and putting them on steroids for decades to come. If youâve implemented support for header units either in compilers or in build systems, I suspect you know what I am talking about đ
The reports Iâve seen from engineers from the trenches who have actually been working on adopting header units in their shipping products are that they are glad the compiler is more strict in its enforcements of âincludableâ/âself containedâ headers as they were discovering pieces of code that should have never left the barn (and sometimes they wondered how they ever ship in the first place). We tend to underestimate the opportunities that engineers have (and are relishing) to strengthen their codebase by over-indexing on âquick adoptionâ which, in my view, is just another handle for âmore technical debt at scaleâ in this context.
-- Gaby
From: Ext <ext-bounces_at_[hidden]socpp.org> On Behalf Of Stephen Kelly via Ext
Sent: Monday, April 25, 2022 2:37 PM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: Stephen Kelly <steveire_at_[hidden]>; ext_at_[hidden]; sg15_at_[hidden]
Subject: Re: [isocpp-ext] [SG15] Fwd: Can we expect that all C++ source files can have the same suffix?
I had concerns about adoption of modules (and dialect splits) 5 years ago and I didn't consider it premature then :)
https://groups.google.com/a/isocpp.org/g/modules/c/sDIYoU8Uljw/m/BKKCSZFdBAAJ?pli=1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fg%2Fmodules%2Fc%2FsDIYoU8Uljw%2Fm%2FBKKCSZFdBAAJ%3Fpli%3D1&data=05%7C01%7Cgdr%40microsoft.com%7C0f3fd77a89834adccca808da2703c491%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865194385287588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BbfVo0ZYnKC3Fb%2BxHBJbfKcIh5TuqFiI69UlIv%2FLTxw%3D&reserved=0>
I guess either time will tell or fresh ideas will remove barriers to adoption. I'll watch with interest.
Thanks,
Stephen.
On Mon 25 Apr 2022, 22:25 Gabriel Dos Reis, <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* Is there any concern that this will harm adoption of modules, or lead to dialects of the language?
As of today, I consider such a worry premature; but I will continue to evaluate data and uses, etc.
-- Gaby
From: Ext <ext-bounces_at_lists.isocpp.org<mailto:ext-bounces_at_[hidden]>> On Behalf Of Stephen Kelly via Ext
Sent: Monday, April 25, 2022 2:20 PM
To: sg15_at_[hidden]<mailto:sg15_at_lists.isocpp.org>
Cc: Stephen Kelly <steveire_at_[hidden]<mailto:steveire_at_[hidden]>>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Subject: Re: [isocpp-ext] [SG15] Fwd: Can we expect that all C++ source files can have the same suffix?
Lots of libraries value such easy quick-starts. If they want to keep the easy quick-start, they will have to provide includable headers and they won't be able to depend on any library that doesn't provide includable headers.
Is there any concern that this will harm adoption of modules, or lead to dialects of the language?
Thanks,
Stephen
On Mon 25 Apr 2022, 21:55 Gabriel Dos Reis via SG15, <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
[Iain]
* With at least two of the current implementations, this is not a viable proposition - since the BMI is dependent on the compile options - therefore there is no single âBMI to installâ - and the set of permutations would be too large to be practicable.
I agreed that prebuilt versions that cover all imaginable combinations of compiler options is not practical. But, again when you look at what they are asking they seem to be pretty happy with some common or âgolden pathâ to run small tests; and Iâve heard them say in the past âit does not need to be perfectâ⌠The approach taken in MSVC (not perfect) is to default to some âcommonly used optionsâ and run experiments with those; that seems to work well for those scenarios. For large scale, serious usage, they canât escape the âyouâve got to graduate to skyscrapers settingsâ.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Iain Sandoe via SG15
Sent: Monday, April 25, 2022 1:06 PM
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]>
Cc: Iain Sandoe <iain_at_[hidden]o.uk<mailto:iain_at_[hidden]>>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Subject: [SG15] Fwd: [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
posted from the wrong address, sorry,
Begin forwarded message:
From: Iain Sandoe <idsandoe_at_[hidden]<mailto:idsandoe_at_[hidden]>>
Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
Date: 25 April 2022 at 21:02:03 BST
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]>
Cc: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>, Steve Downey <sdowney_at_[hidden]<mailto:sdowney_at_[hidden]>>, Peter Dimov <pdimov_at_[hidden]<mailto:pdimov_at_[hidden]>>, Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>>, Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
On 25 Apr 2022, at 19:43, Steve Downey via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
On Mon, Apr 25, 2022 at 1:55 PM Peter Dimov via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Tom Honermann wrote:
On 4/25/22 1:12 PM, Gabriel Dos Reis wrote:
[Peter]
You are correct that the requests don't stop here.
Please, go talk to Tom đ
Let me know when you're on the same page and what the actual request
is đ
I think Peter and I are pretty well aligned. At a minimum, we're aligned on
support for the standard library.
Supporting Boost as Peter suggested would require something like what the
SG15 TR intends to specify or some other form of deeper integration between
the compiler and the Boost installation; I'm content to categorize those
integrations as falling on the sky scraper side. Like Peter, I would like for the
compiler to just support those integrations, but I would also like for build
systems to just never be required at all and I don't see that happening any time
soon :)
Boost here is just an example. The `import <boost/smart_ptr.hpp>` scenario
concerns a header-only library that is, as today, installed somewhere in the
default compiler include path. #include works today, we'd ideally want import
to work tomorrow without additional friction, so that people can painlessly
migrate to using modules.
The Regex scenario describes a C++ compiled library that is installed in the
default include path and the default library path (by e.g. the system package
manager, although not necessarily.) The question here is would it be possible,
in the brave new module world, for the system package manager to install
some things somewhere such that `import <boost/regex.hpp>` or
`import boost.regex` works as well as #include works today.
(I'm assuming here that both libraries have been changed in whatever way
is needed to support modules.)
Possibly for the system compiler, so that the BMI for <boost/smart_ptr.hpp> could be produced upon installation of the boost library.
With at least two of the current implementations, this is not a viable proposition - since the BMI is dependent on the compile options - therefore there is no single âBMI to installâ - and the set of permutations would be too large to be practicable.
Iain
However, this will also make compiler upgrades and secondary compilers a nightmare to install as the entire world gets rebuilt to generate some set of ABI compatible importable objects.
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C0f3fd77a89834adccca808da2703c491%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865194385287588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UCZfqO%2BZyijVb9BuG7OeNgitGn7zWnRBI%2B8A6ENK8nU%3D&reserved=0>
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C0f3fd77a89834adccca808da2703c491%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865194385287588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UCZfqO%2BZyijVb9BuG7OeNgitGn7zWnRBI%2B8A6ENK8nU%3D&reserved=0>
Indeed đ
5 years ago, there was only one implementation of the proposal. 5 years later, we still have only one production-ready implementation of the feature; two are in-flight.
I very much want to discourage us from thinking that a âquickâ path to adoption passes through absorbing the complexity and anarchy of existing header files and putting them on steroids for decades to come. If youâve implemented support for header units either in compilers or in build systems, I suspect you know what I am talking about đ
The reports Iâve seen from engineers from the trenches who have actually been working on adopting header units in their shipping products are that they are glad the compiler is more strict in its enforcements of âincludableâ/âself containedâ headers as they were discovering pieces of code that should have never left the barn (and sometimes they wondered how they ever ship in the first place). We tend to underestimate the opportunities that engineers have (and are relishing) to strengthen their codebase by over-indexing on âquick adoptionâ which, in my view, is just another handle for âmore technical debt at scaleâ in this context.
-- Gaby
From: Ext <ext-bounces_at_[hidden]socpp.org> On Behalf Of Stephen Kelly via Ext
Sent: Monday, April 25, 2022 2:37 PM
To: Gabriel Dos Reis <gdr_at_microsoft.com>
Cc: Stephen Kelly <steveire_at_[hidden]>; ext_at_[hidden]; sg15_at_[hidden]
Subject: Re: [isocpp-ext] [SG15] Fwd: Can we expect that all C++ source files can have the same suffix?
I had concerns about adoption of modules (and dialect splits) 5 years ago and I didn't consider it premature then :)
https://groups.google.com/a/isocpp.org/g/modules/c/sDIYoU8Uljw/m/BKKCSZFdBAAJ?pli=1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fisocpp.org%2Fg%2Fmodules%2Fc%2FsDIYoU8Uljw%2Fm%2FBKKCSZFdBAAJ%3Fpli%3D1&data=05%7C01%7Cgdr%40microsoft.com%7C0f3fd77a89834adccca808da2703c491%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865194385287588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BbfVo0ZYnKC3Fb%2BxHBJbfKcIh5TuqFiI69UlIv%2FLTxw%3D&reserved=0>
I guess either time will tell or fresh ideas will remove barriers to adoption. I'll watch with interest.
Thanks,
Stephen.
On Mon 25 Apr 2022, 22:25 Gabriel Dos Reis, <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* Is there any concern that this will harm adoption of modules, or lead to dialects of the language?
As of today, I consider such a worry premature; but I will continue to evaluate data and uses, etc.
-- Gaby
From: Ext <ext-bounces_at_lists.isocpp.org<mailto:ext-bounces_at_[hidden]>> On Behalf Of Stephen Kelly via Ext
Sent: Monday, April 25, 2022 2:20 PM
To: sg15_at_[hidden]<mailto:sg15_at_lists.isocpp.org>
Cc: Stephen Kelly <steveire_at_[hidden]<mailto:steveire_at_[hidden]>>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Subject: Re: [isocpp-ext] [SG15] Fwd: Can we expect that all C++ source files can have the same suffix?
Lots of libraries value such easy quick-starts. If they want to keep the easy quick-start, they will have to provide includable headers and they won't be able to depend on any library that doesn't provide includable headers.
Is there any concern that this will harm adoption of modules, or lead to dialects of the language?
Thanks,
Stephen
On Mon 25 Apr 2022, 21:55 Gabriel Dos Reis via SG15, <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
[Iain]
* With at least two of the current implementations, this is not a viable proposition - since the BMI is dependent on the compile options - therefore there is no single âBMI to installâ - and the set of permutations would be too large to be practicable.
I agreed that prebuilt versions that cover all imaginable combinations of compiler options is not practical. But, again when you look at what they are asking they seem to be pretty happy with some common or âgolden pathâ to run small tests; and Iâve heard them say in the past âit does not need to be perfectâ⌠The approach taken in MSVC (not perfect) is to default to some âcommonly used optionsâ and run experiments with those; that seems to work well for those scenarios. For large scale, serious usage, they canât escape the âyouâve got to graduate to skyscrapers settingsâ.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Iain Sandoe via SG15
Sent: Monday, April 25, 2022 1:06 PM
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]>
Cc: Iain Sandoe <iain_at_[hidden]o.uk<mailto:iain_at_[hidden]>>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Subject: [SG15] Fwd: [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
posted from the wrong address, sorry,
Begin forwarded message:
From: Iain Sandoe <idsandoe_at_[hidden]<mailto:idsandoe_at_[hidden]>>
Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
Date: 25 April 2022 at 21:02:03 BST
To: sg15_at_[hidden]<mailto:sg15_at_[hidden]>
Cc: Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>, Steve Downey <sdowney_at_[hidden]<mailto:sdowney_at_[hidden]>>, Peter Dimov <pdimov_at_[hidden]<mailto:pdimov_at_[hidden]>>, Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>>, Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
On 25 Apr 2022, at 19:43, Steve Downey via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
On Mon, Apr 25, 2022 at 1:55 PM Peter Dimov via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
Tom Honermann wrote:
On 4/25/22 1:12 PM, Gabriel Dos Reis wrote:
[Peter]
You are correct that the requests don't stop here.
Please, go talk to Tom đ
Let me know when you're on the same page and what the actual request
is đ
I think Peter and I are pretty well aligned. At a minimum, we're aligned on
support for the standard library.
Supporting Boost as Peter suggested would require something like what the
SG15 TR intends to specify or some other form of deeper integration between
the compiler and the Boost installation; I'm content to categorize those
integrations as falling on the sky scraper side. Like Peter, I would like for the
compiler to just support those integrations, but I would also like for build
systems to just never be required at all and I don't see that happening any time
soon :)
Boost here is just an example. The `import <boost/smart_ptr.hpp>` scenario
concerns a header-only library that is, as today, installed somewhere in the
default compiler include path. #include works today, we'd ideally want import
to work tomorrow without additional friction, so that people can painlessly
migrate to using modules.
The Regex scenario describes a C++ compiled library that is installed in the
default include path and the default library path (by e.g. the system package
manager, although not necessarily.) The question here is would it be possible,
in the brave new module world, for the system package manager to install
some things somewhere such that `import <boost/regex.hpp>` or
`import boost.regex` works as well as #include works today.
(I'm assuming here that both libraries have been changed in whatever way
is needed to support modules.)
Possibly for the system compiler, so that the BMI for <boost/smart_ptr.hpp> could be produced upon installation of the boost library.
With at least two of the current implementations, this is not a viable proposition - since the BMI is dependent on the compile options - therefore there is no single âBMI to installâ - and the set of permutations would be too large to be practicable.
Iain
However, this will also make compiler upgrades and secondary compilers a nightmare to install as the entire world gets rebuilt to generate some set of ABI compatible importable objects.
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C0f3fd77a89834adccca808da2703c491%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865194385287588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UCZfqO%2BZyijVb9BuG7OeNgitGn7zWnRBI%2B8A6ENK8nU%3D&reserved=0>
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C0f3fd77a89834adccca808da2703c491%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865194385287588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UCZfqO%2BZyijVb9BuG7OeNgitGn7zWnRBI%2B8A6ENK8nU%3D&reserved=0>
Received on 2022-04-25 21:49:29