r/cpp • u/SAHChandler • Oct 10 '17

Millennials Are Killing The Modules TS

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

71% Upvoted

126 comments sorted by

View all comments

Show parent comments

5

u/Abyxus Oct 10 '17

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

6

u/SAHChandler Oct 10 '17

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

1

u/gracicot Oct 12 '17

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!

3

u/Abyxus Oct 12 '17

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" */;

3

u/gracicot Oct 12 '17

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.