c++17 namespaces, is it possible to force qualified access ALWAYS? - c++

Question

to my surprise, when a function is declared in the same namespace as a variable, the function may access that variable without qualification.
// file qqq.cpp
namespace aaa {
void f();
int x;
}
void aaa::f() {
aaa::x; // 0. INTENDED ACCESS to x in namespace aaa (also works)
x; // 1. SURPRISE: x can be accessed without aaa:: qualification
bool x; // 2. SURPRISE: given (1) why is it allowed to redefine x?
}
question:
A) is there any way to ensure that all objects in a namespace be blind to its fellow constituents, and to require access always through :: ?
B) if not, what would be the correct coding practice to obtain the desired behavior?
C) if not, an alternative solution would be to separate the each namespace into 2, one for functions and another for variables, like f_aaa and v_aaa. but this seems quite clunky and ugly in practical use, eg. void f_sqlite::myfun() { v_sqlite::myvar; } instead of just void sqlite::myfun() { sqlite::myvar; }
edit 1: context, the "problem" im trying to solve:
refactoring several thousand lines of code, namespaces was thought to be suitable for bundling related elements, eg. an "sqlite" namespace for sqlite utility functions and variables used throughout the code base. forced access through :: would be an excellent way of increasing clarity and avoiding name clashes and hiding. separate namespaces for "one bundle" would defeat the purpose. classes would not seem conceptually appropriate.
edit 2:
D) is it possible to get a WARNING (enable compiler flag) to signal when a function in namespace aaa accesses a variable in namespace aaa without qualification?
edit 3:
i think i will end up using "separate namespaces" anyway, but by way of nested namespaces
// file qqq.cpp
namespace aaa::f { // namespace for functions
void f();
void g();
}
namespace aaa::v { // namespace for variables
int x;
}
// definition of function f inside namespace aaa::f
void aaa::f::f() {
aaa::v::x; // only way of accessing x in aaa::v (good) (ugly)
x; // compiler error (good)
bool x; // normal scope hiding (good)
g(); // works: ARGH! would like to force qualifying with aaa::f::
}
still rather ugly though. and! functions can still call each other unqualified, objects can still call/reference each other unaqulified. would really have been nice to simply be able to put some "force-qualifier" (like "private") on all or some element inside a namespace.

Answer 1

A) is there any way to prevent all objects in a namespace to be blind to its fellow constituents, and to require access always through :: ?
There isn't.
B) if not, what would be the correct coding practice to obtain the desired behavior?
Use a class.
C) if not, an alternative solution would be to separate the aaa namespace into 2, one for functions and another for variables, like f_aaa and v_aaa. but this seems quite clunky and ugly in practical use, eg. void f_sqlite::myfun() { v_sqlite::myvar; } instead of just void sqlite::myfun() { sqlite::myvar; }
Use a class to group relevant functions and data together. What You want to hide put in a private section.

Answer 2

Using a separate (nested) namespace for function and variable is not a good idea. It make the code less readable.
Also always qualifying all names is overkill. If the function f is in namespace aaa then it should really prefer variables from that namespace.
And finally the only reason why you would have such problem is because you are using too much global variables (or long functions) which is really a bad practice because it make the code harder to maintain.
So I recommend you to use to use good coding practices like
small functions (less than a screen)
avoid global variables
object-oriented design using class with member functions and data when appropriate.
small files (so you don't get irrelevant stuff)
avoid variables in header files
include only the files you really need (thus you won't get many conflicts if any)
In fact, if you really have the issue you have, it is because current code is large and don't follow good practices..
Other workarounds in comments and answers might works but better to validate if your design is adequate and refactor your code as appropriate.
Extra points:
Another thing that might cause lot of ambiguities is to use basic data type when you should really use custom types.
Uses typed enumeration (enum class) when you want to use some constant for specific parameter instead of define or integers.
Uses class or struct if you have data that are bundled together and are used all over the application.
If you use template functions, you might want to carefully consider what kind of data it would allows particularly if you have a common name like open for the function.