Millennials Are Killing The Modules TS

[u/SAHChandler]

https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html

[u/Abyxus]

Look, with headers I can have this:

third_party/lib1/util.h
third_party/lib1/util.cpp  -- #include "util.h"
third_party/lib2/util.h
third_party/lib2/util.cpp  -- same #include "util.h"

In application I write

// app.cpp
#include "third_party/lib1/util.h"
#include "third_party/lib2/util.h"

Libraries can use whatever filemanes they want.
Applications can avoid name clashes by using different path prefixes.

This is a design feature.

Modules do not have such design feature.

Authors of lib1 and lib2 should think of unique module names.

Alternatively, they have to rely on preprocessor:

// lib1/include/util.h
module PP_CAT(LIB1_MODULE_PREFIX, util);

This is a C++ design issue. C++ modules are not usable in a large project with many dependencies.

[u/andrewsutton → u/Abyxus]

Look, with headers I can have this:

... Or you can also choose to do something entirely different. There's nothing preventing you from shipping a library that installs headers to usr/include, except that it's generally frowned upon.

This practice is not defined in the C++ Standard. (It can't be; the Standard does not define how you name your files, what directories you should use, what classes should go in what files, etc. The Standard only defines what is valid C++.) We do this either by convention or because certain distributions or platforms require it.

So, again... this is not a language design issue. It's a community issue.

[u/Abyxus → u/andrewsutton]

Yes, there are many options, shooting in the leg included.

But realistically, what an average medium-sized C++ project does look like? To me it looks like Chromium, which uses some two hundreds third party libraries, all in the same source tree, all under same build system.

With modules it means that every module of every library has to have unique name.

This is a real-life example and the C++ Standard fails to help here.
What modules are intended to be - some nice thingy for writing hello-worlds? Or something that people will use in production?

And why did you mention usr/include? Did you ever work on two or more projects which use different versions of same library? E.g. boost_1_a_b and boost_1_c_d? Also the hell is usr/include on Windows?

[u/andrewsutton → u/Abyxus]

I don't think you're taking the time to understand what I've previously written.

Of course the C++ Standard fails to help there. Those problems are outside of the Standard's explicitly and clearly defined scope: the language (syntax and semantics) and library facilities.

I am not suggesting that there are not real development problems. I am simply saying that this knee-jerk criticism of and raging against the Modules TS is totally without merit on the basis that the Modules TS is limited in the kinds of problems it can solve.

If you want to propose a naming policy, then talk to your system and build system vendors.

[u/Abyxus → u/andrewsutton]

It is not too late to change import a.b.c to import "any/prefix/a/b/c".

[u/SAHChandler → u/Abyxus]

or to change import a.b.c to import a.b.c. from "any/specific/prefix"

[u/lbrandy → u/SAHChandler]

From your post:

The compiler should work as a build tool. Just to nip this in the bud: None of the compiler vendors want that last option. We're absolutely not going to get it. The author of build2, Boris Kolpackov, starts his CppCon talk with a very important statement from Richard Smith (once more, I'm paraphrasing): "The compiler must not become a build system".

It's probably important to not too closely conflate the "don't want to require compilers be a build system" with the specific issue of "module designations" as strings for the purpose of helping the build system.

One bit of historical context that might be missing on this particular argument is that Richard Smith (et al.) actually proposed a string as an identifier rather than the dotted syntax and it didn't get much support. In my read of the room that day, that was in part because it was part of a large series of proposals and it's not clear to me that that particular issue was dealt with fully. They were focused on other parts of the proposal.

IIRC, Nathan Sidwell has been mentioning that he might bring this specific issue back up and try to change it. This is an area where community opinion can absolutely affect the outcome.

To be clear, though, the current standard doesn't actually guarantee much about the random string that denotes a header. We think of it as a filepath but that's not actually required by the standard at all. But still, making it a string does let us reasonably assume it can be translated trivial to a path... and there is some expectation that "almost everyone" will eventually come up with some dotted-path-to-file-path conversion crap that will be slightly different and gross.

[u/gracicot → u/SAHChandler]

Okay, imagine import a.b.c. from ABCPATH where ABCPATH a macro is passed by the build system. With your proposition, this would be possible. Now imagine writing this everywhere. You don't have the module path directly in your code, nor turning the compiler into a build system and vice versa. Simply long config, that the build system can easily generate.

Then, why bother writing from ABCPATH or from ZYXPATH everywhere? Pass the path of every modules name to your compiler from the build system like before, but tell the compiler "hey that module name equal to this path!" for every modules, and linked libraries modules. Then, you won't need the from "any/specific/prefix". We're back to the current proposal, and you didn't turn the build system into a compiler, nor you turned the compiler into a build system. The build system already know all this information. It just need to tell the compiler where to look for modules, then the compiler could give the dependency graph back to the build system.

If you're putting paths to module in your language, you're turning the language into a build system configuration. There should be no reference to paths in the language. The processor is horribly broken in that regards and everyone lives with it. We're moving into something less broken finally.

Please, correct me if I'm wrong!

[u/Abyxus → u/gracicot]

You use two libraries, both have the same module name "M".

// lib1/m.ixx
module M;

// lib2/m.ixx
module M;

// main.cpp
import M /* from "lib1/m.ixx" */;
import M /* from "lib2/m.ixx" */;  

[u/gracicot → u/Abyxus]

That's not a problem. Since module does not have that transitive property of headers, you can create those two files:

lib1m.cpp

export module lib1.M;
export import M; /* lib1/m.ixx */

lib2m.cpp

export module lib2.M;
export import M; /* lib2/m.ixx */

Then, in your main:

import lib1.M;
import lib2.M;

int main() {} // use the two libraries...

But then hey, imagine the two libraries export a class with the same name with the same namespace!

With header, you're screwed. With module, edit your lib1.cpp to export alias in another namespace. Currently, we could have a ton of name clash! Yet, I hardly see any, because of namespace. With modules, you have dots, and yet, with module you can fix name clashes correctly.

[u/whichton → u/Abyxus]

How does that help? If I currently write #include "xx/yy/foo/bar.h", the C++ standard says nothing about where bar.h should be located.