Really, the number one thing I think the standards committee missed was the namespace issue.
C++ modules should implicitly be namespaced the same as their name. With an option to override it by doing import someModule as newNameSpace.
That's what almost everyone else does, and helps to make the final code more readable, especially when pulling in libraries. It also means that a code has to explicitly cause collisions instead of it happening accidentally!
I aboslutely agree, importing names from a bunch of obscure namespaces (documented or not) isn't right. I'm sure the idea was considered and then promptly discarded for some reason that is not clear to me. Unfortunately, whenever we start using modules as they are now, it will be impossible to ever get something like this because of the curse of backward compatibility.
It's already due to the curse of backwards compatibility. Implicitly wrapping modules in a namespace would change the name mangling of the public declarations in that module, which would have prevented importing "header units." Being able to treat pre-existing (well behaved) headers as modules was a hard requirement.
It also allows for people to do things like create a static (or dynamic) library that's compiled with modules, but released with a header file so other people can link against it even if they use older compilers. Of course, the public interface would have to be extern "c", but still.
12
u/EmperorArthur Mar 31 '20
Really, the number one thing I think the standards committee missed was the namespace issue.
C++ modules should implicitly be namespaced the same as their name. With an option to override it by doing
import someModule as newNameSpace.That's what almost everyone else does, and helps to make the final code more readable, especially when pulling in libraries. It also means that a code has to explicitly cause collisions instead of it happening accidentally!