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