On 4/25/22 6:54 PM, Gabriel Dos Reis via SG15 wrote:
>
> [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.
>
I've always found Patrice to be an exceptionally polite person.
Unfortunately, I'm not as kind. Gaby, the "some implementors" are you :)

Ignore the prior 100+ previous emails. Patrice's request was: 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.

So, let's do that. Here is an example that can be compiled simply by the
Visual C++ compiler driver today.

> type t.cpp
#include <iostream>
int main() {
   std::cout << "👋 Gaby\n";
}

> cl /EHsc /nologo /Fet.exe /std:c++latest t.cpp
t.cpp

Now let's change the example to use a header unit. To build it, it is
currently necessarily to manually build a .ifc file for <iostream>.

> type t.cpp
import <iostream>;
int main() {
   std::cout << "👋 Gaby\n";
}

> cl /EHsc /nologo /Fet.exe /std:c++latest /headerName:angle
/exportHeader iostream
iostream
> cl /EHsc /nologo /Fet.exe /std:c++latest /headerUnit:angle
iostream=iostream.ifc t.cpp
t.cpp

And change it to use a named module:

> type t.cpp
import std;
int main() {
   std::cout << "👋 Gaby\n";
}

> cl /EHsc /nologo /Fet.exe /std:c++latest t.cpp
t.cpp
t.cpp(1): fatal error C1011: cannot locate standard module interface.
Did you install the library part of the C++ modules feature in VS setup?

Ah, right, MSVC doesn't implement the std module yet. But I appreciate
that the attempted use was acknowledged by the diagnostic!

Tangent: I tried the above example substituting std.core for std, but
still couldn't get it to build successfully. I kept getting the same
diagnostic as above even though the VS installer claims the modules are
installed for my MSVC 16.13.11 installation. It is absolutely possible
that I'm doing something wrong here. Of course, if I did need to build a
.ifc file for the std module, I wouldn't know how to do so.

Anyway, back to Patrice's request. Gaby (and any other implementors),
can you explain why having the compiler driver automate these tasks,
just for the standard library, would be unreasonable? I think it is
worth noting that the MSVC compiler already supports the ability to
create some files on demand per the #import directive
<https://docs.microsoft.com/en-us/cpp/preprocessor/hash-import-directive-cpp?view=msvc-170>;
the "Header files created by import"
<https://docs.microsoft.com/en-us/cpp/preprocessor/hash-import-directive-cpp?view=msvc-170#_predir_the_23import_directive_header_files_created_by_import>
section seems particularly related.

Tom.

> -- Gaby
>
> *From:* Ext <ext-bounces_at_[hidden]> *On Behalf Of *Patrice Roy
> via Ext
> *Sent:* Monday, April 25, 2022 3:42 PM
> *To:* sg15_at_[hidden]
> *Cc:* Patrice Roy <patricer_at_[hidden]>; Nathan Sidwell
> <nathan_at_[hidden]>; Tom Honermann <tom_at_[hidden]>; Peter Dimov
> <pdimov_at_[hidden]>; Evolution Working Group mailing list
> <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]> a écrit :
>
> On Mon, Apr 25, 2022 at 1:55 PM Peter Dimov via Ext
> <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]
> 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%7C41538b05ec864edfe20608da270cd536%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865233315597264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NTUdedQeAWXuS6pcQgPAsaCbF5Fyv%2FzmUYbxUIkDMzo%3D&reserved=0>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15