I only asked a question that your assertion begged. It sounds like I may never get an answer... Oh well :-)

-- Gaby

________________________________
From: Patrice Roy <patricer_at_[hidden]>
Sent: Monday, April 25, 2022 4:54:40 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: ext_at_[hidden] <ext_at_[hidden]>; sg15_at_[hidden] <sg15_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?

Well, it's actually simpler than this : if there is (as you seem to assert) no evidence of resistance to making Tom's std-lib-only program compile, then it's a done deal, and I thank you :)

However, if that's not the case, then my question stands.

Thanks!

Le lun. 25 avr. 2022 à 19:35, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> a écrit :
Yes, because it is important that we proceed from the same observed evidence.

I am assuming you didn't make the assertion without evidence, so it shouldn't that long to exhibit, no?

-- Gaby

________________________________
From: Patrice Roy <patricer_at_[hidden]<mailto:patricer_at_[hidden]>>
Sent: Monday, April 25, 2022 4:00:41 PM
To: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Cc: ext_at_lists.isocpp.org<mailto:ext_at_[hidden]> <ext_at_[hidden]<mailto:ext_at_[hidden]>>; sg15_at_[hidden]<mailto:sg15_at_[hidden]> <sg15_at_[hidden]<mailto:sg15_at_[hidden]>>; Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>; Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>>; Peter Dimov <pdimov_at_[hidden]<mailto:pdimov_at_[hidden]>>
Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?

I can do a full recension but it would take time. Do you require this given that we're at way more than 100 messages? It would seem just explaining what the problem is would be more efficient.

However, should there be a need for a recension of past messages in this thread, it can be done. Just not tonight.

Cheers!

Le lun. 25 avr. 2022 à 18:54, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> a écrit :

[Patrice]

  * […] there seems to be strong resistance from some implementers as to supporting Tom's "Congrats Gaby" hello-world-style program that would only depend on a modularized standard library (let's leave Boost and other well-known but non-std libraries for the moment). This resistance would be hard to explain to users without knowing more about the reasons for this resistance.



To ensure that we are all talking about the same conversation, could you point to actual evidence of that resistance and the “some implementers”? I want to ensure that we are addressing real resistance.



-- Gaby





From: Ext <ext-bounces_at_[hidden]<mailto:ext-bounces_at_[hidden]>> On Behalf Of Patrice Roy via Ext
Sent: Monday, April 25, 2022 3:42 PM
To: sg15_at_lists.isocpp.org<mailto:sg15_at_[hidden]>
Cc: Patrice Roy <patricer_at_[hidden]<mailto:patricer_at_[hidden]>>; Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>; Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>>; Peter Dimov <pdimov_at_[hidden]<mailto:pdimov_at_[hidden]>>; Evolution Working Group mailing list <ext_at_[hidden]<mailto:ext_at_[hidden]>>
Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?



I think a piece from this discussion is missing : there seems to be strong resistance from some implementers as to supporting Tom's "Congrats Gaby" hello-world-style program that would only depend on a modularized standard library (let's leave Boost and other well-known but non-std libraries for the moment). This resistance would be hard to explain to users without knowing more about the reasons for this resistance.



Would an implementer care to explain why this seems so unreasonable without a build system? Ideally, comparing the "old-style" (lexically included headers) approach to the modules-based approach.



From this, it would at least be easier to explain to beginners why just compiling their simple, standard-library-only programs requires more tooling than it used to. Everyone would benefit from that knowledge, or so it seems to me. My users are game programmers; they are experienced, they use build systems, but they also compile small test code manually at the command line and if they cannot use modules for this, they will ask why and I would really like to have an answer. It's not a sand-castle vs skyscraper issue; it's something they will need to know to integrate it in their workflow.



Thanks in advance!





Le lun. 25 avr. 2022 à 14:44, Steve Downey via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> a écrit :





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.

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]p.org<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%7C6b1e7b0893b34056ca0908da2716fe81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865276958781109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mZPd8A6gPRtmBSwUgn1O5vd5KbVgKnn3r2i4ZMr3WBQ%3D&reserved=0>