So... Thinking "out loud" a bit. We've got two groups of users that
might be "surprised" by modules CLI behavior:

 1. New C++ Developers
 2. Experienced C++ Developers

I think the "New C++ Developers" are likely to get into C++ using
Microsoft's Visual Studio, JetBrain's CLion, or some similar IDE-like
product. I think back to my "first steps" with Java and to this day I
don't think I've ever directly invoked javac despite writing hundreds of
thousands of lines of Java code.

In the "Experienced C++ Developers" case, I think the risk of shock is
much higher (and this does have an impact on students indirectly via
confusing professors). I think there's a disproportionate number of C++
developers that (for various reasons) prefer a simpler text editor and
CLI vs an IDE.

I haven't personally used GCC and its module mapper. However, I think
this is somewhat related to Iain's previous (in person) comments about
how the module mapper can be "quite nice" for smaller projects (per my
understanding by building modules on demand from a presumably relatively
simple -- ? -- compile command). I'm not sure the module mapper
currently builds the std module implicitly or anything of that sort, but
I wouldn't be surprised by such behavior.

There's also a difference in C++ developers on Windows vs C++ developers
on Linux ... because Windows in general is (historically) more GUI
driven vs Linux which is (historically) more CLI driven.


... given all of that, I'd say the answer to "Should the compiler try to
build std module implicitly?" is: leave it up to the compiler. I suspect
Gaby's answer is exceedingly correct for the Microsoft ecosystem but a
"simple CLI" might be more appropriate for GCC, Clang,and /perhaps/ EDG.
A compiler driver that interacts with or spawns a module mapper (or
something similar) isn't a big jump from the possible "wrapper around
the compiler" that Gaby mentioned.

In general, I don't think the problem is really about the std module, I
think it's more related to platform ergonomics and how developers
typically work with their compiler (really hands on and direct, or more
hands off as an implementation detail). I don't think that will be
solved in this thread.

Thus, the more notable conclusion I think is we don't want to
/discourage/ implementations from implicitly building the standard
module (or any other module) they want; but I don't think we want to
/encourage/ that behavior either.

- Wyatt

On 12/4/23 11:04, Gabriel Dos Reis via SG15 wrote:
>
> * Before we jump into the details and other topics, let's sure if we
> are interested in the raised topic (should the compiler treat std
> module specially to make it easier for beginners and small projects)
>
> I agree with the goal of providing a simple command-line interface to
> C++ compiler for small programs; I don’t, however, think that it goes
> through implicitly compiling “std”.
>
> I agree with Boris’s general observations.
>
> I think a **wrapper** around the compiler that generates the
> dependencies and builds the needed BMI might be a more promising and
> better route.
>
> -- Gaby
>
> *From:*SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Chuanqi Xu
> via SG15
> *Sent:* Monday, December 4, 2023 1:31 AM
> *To:* SG15 <sg15_at_[hidden]>
> *Cc:* Chuanqi Xu <chuanqi.xcq_at_[hidden]>
> *Subject:* Re: [SG15] [Modules] Should the compiler try to build std
> module implicitly?
>
> Hi Ran,
>
> Before we jump into the details and other topics, let's sure if we
> are interested in the raised topic (should the compiler treat std
> module specially to make it easier for beginners and small projects).
> And if I read correctly, you're agree with the direction?
>
> Then there are some details about modules.
>
> > I am not sure we must start with the source code of every library we
> want to import (including the standard).
>
> Currently, the consensus are, we need to compile the modules we're
> importing locally since we agree that the BMIs are not ready to be
> distributed at least for now. (Let's ignore distributed build
> temporarily).
>
> Then in the same machine, can we reuse the BMIs across different
> projects if possible? I think it is possible but I am not sure which
> build systems implemented this.
>
> So generally, it'd better to treat BMIs as by-product and assume we
> need to build modules from source.
>
> > In the BMI-well-known-place (like headers).
>
> But we don't have one. And as far as I know, no one is proposing this
> in detail.
>
> > Sure. Without this ability we are doing wrong. Std shouldn't be special.
>
> But stl (without modules) is already special to me. The compiler
> knows the position of headers. The compiler are able to link the
> standard libraries automatically. Also the standard libraries use some
> special intrinsics and special pragma to implement themselves. So I
> think std can be special, while it may not be necessary.
>
> Thanks,
>
> Chuanqi
>
> Thanks,
>
> Chuanqi
>
> ------------------------------------------------------------------
>
> From: SG15 <sg15_at_[hidden]>
>
> Send Time:2023 Dec. 4 (Mon.) 15:34
>
> To: SG15 <sg15_at_[hidden]>
>
> Cc:Ran Regev <regev.ran_at_[hidden]>
>
> Subject:Re: [SG15] [Modules] Should the compiler try to build std
> module implicitly?
>
> On Mon, Dec 4, 2023, 08:00 Chuanqi Xu via SG15
> <sg15_at_[hidden]> wrote:
>
> Hi Guys,
>
> This post is mainly about some random thoughts about
> teachability of std modules. Also [P2412R0: Minimal module support
> for the standard library]
> (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf)
> mentions that the std module is important for educations and
> beginners. If there are more interests, I can try to summarize
> them into a paper.
>
> When I start to learn C++, I only need to copy a hello world
> example and run:
>
> ```
>
> clang++ hello.cpp -o hello
>
> ```
>
> If the code of hello.cpp is similar to the example below (just
> include instead of import) then even in this example the compiler
> did a "magic" for you by finding this include without your
> specific direction. It simply "knew" where to search.
>
> However, with the current direction of std modules, the beginner
> need to install the build systems and try to copy the build
> scripts that them can hardly understand. Possibly some simpler
> form of https://libcxx.llvm.org/Modules.html. But it still seems
> scaring to beginners.
>
> The same mechanism that is used by compilers to find includes may
> be used to find modules.
>
> And I am wondering if we can simplify the process. For example,
> the beginners can compile a hello world example with std module:
>
> ```
>
> import std;
>
> int main() { std::cout << "Hello modular world\n"; }
>
> ```
>
> with a single command line:
>
> ```
>
> clang++ -std=c++23 hello.cpp -o hello
>
> ```
>
> The compiler may achieve that when:
>
> - the std module is required but not provided.
>
> - the path to std module's BMI is not specified. (implied that the
> invocation doesn't from build systems)
>
> - the final output is an executable.
>
> - the std module's source exists in the installed path (being
> discussed in https://github.com/llvm/llvm-project/issues/73089).
>
> I am not sure we must start with the source code of every library
> we want to import (including the standard). It feels like that if
> we had a place for BMIs then we are good to go using them. There
> is a question what to do when they are missing. Maybe an error,
> not trying to build from source.
>
> then the compiler can try to compile the std module's source to
> BMI and object file. Then we can import the BMI and link the
> object file. There are some details. e.g., where should we put the
> BMI?
>
> In the BMI-well-known-place (like headers).
>
> Should we try to reuse the BMIs?
>
> Yes.
>
> Can we extend the process to other modules?
>
> Sure. Without this ability we are doing wrong. Std shouldn't be
> special.
>
> They are open questions and my answers are:
>
> - By default, they should be in `/tmp` and if `-save-temps` is
> specified, they'll be in the same directory with the temporaries.
>
> I don't agree. BMI should be reused as far as I understand.
>
> - The compiler shouldn't try to reuse the BMIs. That is the job of
> the build systems.
>
> I think that as source files are the input of #incluse, BMI should
> be the input of import. Therefore the compiler should try and find
> ONLY BMIs when it sees import directive. It is the build system to
> make sure they exists.
>
> - No, we can't. It is possible for std module since we'll try to
> standardize the locations of std modules sources. So that the
> tools are able to find the source of std modules. But it is not
> the case for other generalized modules. Also I think this is the
> job of build systems too.
>
> I disagree. Std and other modules should behave the same.
>
> The motivation is primarily for beginners and educations. How do
> you feel about the idea?
>
> Thanks,
>
> Chuanqi
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15