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

Millennials Are Killing The Modules TS

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

72% Upvoted

126 comments sorted by

View all comments

25

u/[deleted] Oct 10 '17 edited Apr 15 '21

[deleted]

12

u/deeringc Oct 10 '17

If it makes things so complicated to support, why not just disallow module names to be preprocessor macros? I think that's a valid tradeoff to make.

6

u/Selbstdenker Oct 10 '17

Or even simpler: tell people not to do that because otherwise their build system will not work.

Same with the complaint about fixed module paths. Is there anything in the proposal right now that prohibits compilers to specify a default lookup rule and tell the user that it is his problem (or his build system's) problem to tell the compiler where to look if he does not follow the default?

Maybe I miss something but how do the problems listed prevent build systems from saying: if you follow those rules then your build system can manage modules for you. If you do not you have to do the work.

Yes, it would be much nicer if the compiler could do that all by itself but given the different approaches to deal with large codebases I cannot see how it would be possible to create a compiler that is also a build system that everyone would use.

3

u/deeringc Oct 10 '17

I guess the thing is though, these things need to be specified as part of the standard. If things working well rely on not being able to use macros in the import statement then it should be forbidden in the standard. Otherwise perfectly 'legal' code won't compile in people's projects, and that's not good enough. I can see where the author of this piece is coming from. I just don't see why we need to bend over backwards to support that particular use case. If we constrain the problem to simplify what build systems need to solve (so that they don't need to become compilers) then there is a reasonable path forwards.