[Tom]
> I think Peter and I are pretty well aligned. At a minimum, we're aligned
> on support for the standard library.

I asked if the requests would stop there, you said " Yes, I believe so."; Peter said actually I am "correct that the requests don't stop there".
One of those is true, but not both simulttaenously.

-- Gaby


-----Original Message-----
From: Tom Honermann <tom_at_honermann.net>
Sent: Monday, April 25, 2022 10:43 AM
To: Gabriel Dos Reis <gdr_at_microsoft.com>; Peter Dimov <pdimov_at_gmail.com>; sg15_at_lists.isocpp.org; 'Daniel Ruoso' <daniel_at_ruoso.com>
Cc: 'Nathan Sidwell' <nathan_at_[hidden]>; ext_at_lists.isocpp.org
Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?

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 :)

Tom.

>
> -- Gaby
>
> -----Original Message-----
> From: Peter Dimov <pdimov_at_gmail.com>
> Sent: Monday, April 25, 2022 10:04 AM
> To: Gabriel Dos Reis <gdr_at_microsoft.com>; sg15_at_lists.isocpp.org; 'Daniel Ruoso' <daniel_at_ruoso.com>
> Cc: 'Nathan Sidwell' <nathan_at_acm.org>; 'Tom Honermann' <tom_at_honermann.net>; ext_at_lists.isocpp.org
> Subject: RE: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>
> Gabriel Dos Reis wrote:
>> [Peter]
>>> All that's also true without modules, but we still make it possible
>>> for
>>>
>>> c++ hello.cc
>>>
>>> to produce a working hello world executable without the user
>>> explicitly providing a bunch of -I, -L, -l options, or having to build
>>> the standard library first.
>> Show me the content of hello.cc and we see if this audience agrees on the
>> requirements.
> In this specific message I had the following hello.cc programs in mind:
>
> (1)
>
> #include <iostream>
>
> int main()
> {
> std::cout << "Hello, world" << std::endl;
> }
>
> (2)
>
> import <iostream>;
>
> int main()
> {
> std::cout << "Hello, world" << std::endl;
> }
>
> (3)
>
> import std;
>
> int main()
> {
> std::cout << "Hello, world" << std::endl;
> }
>
> You are correct that the requests don't stop here. Given that
>
> (4)
>
> #include <boost/smart_ptr.hpp>
>
> int main()
> {
> boost::shared_ptr<int> p( new int );
> }
>
> works today after `apt install libboost-dev`, I would also prefer for
>
> (5)
>
> import <boost/smart_ptr.hpp>;
>
> int main()
> {
> boost::shared_ptr<int> p( new int );
> }
>
> to work. And given that
>
> (6)
>
> #include <boost/regex.hpp>
>
> int main()
> {
> boost::regex r;
> }
>
> works today (after `apt install` and appending `-lboost_regex` to the
> command line), ideally, I would also prefer for
>
> (7)
>
> import <boost/regex.hpp>;
>
> int main()
> {
> boost::regex r;
> }
>
> or
>
> (8)
>
> import boost.regex;
>
> int main()
> {
> boost::regex r;
> }
>
> to work (after `apt install` and possibly, but not necessarily, after appending
> something containing `boost_regex` on the command line.)
>
> Now, obviously, I don't necessarily insist that all of these _must_ work. I'm
> giving them as a reference so that any of us can state which of these need,
> in his/her opinion, work, and which do not have to.
>
> Myself, I would prefer all of these to work. In 202x, we want programmers
> to write the module-using programs, and not the "legacy" ones. But it's a
> tradeoff.
>
>