> I do not agree. If people need "using namepsace" they can do it in the
> current proposal but alot of people (such as myself) do not need it and
> your sugestion would force it for these people. I wouldn't use "using
> namespace" for ANY big namespace with alot of common names (one good
> example is "std" where it makes sense to write "std::list" as oposed to
> just "list" since in a big project you have several kinds of lists from
> various places).
Please. Read the proposal before answering because I think you didn't:
1.- The import directive won't force anyone not to fully qualify names
if they want to.
2.- You can disambiguate std::list or mylib::list if you want to, as
you would do anyway.
> BTW, I am one of those having alot of nested namespaces (max 3 levels, but I
> do have alot of 2 levels namespaces) and I don't mind at all the verbosity
> especially since you can opt it out with "using namespace", "using" or
> namespace aliases to make local short aliases for longer namespaces (such
> as I do for "boost::filesystem" which usually gets a "bfs" alias almost
> everywhere in non-header code).
You could still use namespace aliases, but you won't need them. And
that's good
because you say you use namespace aliases to shorten names, and with
this you wouldn't
need to shorten anything because it would be taken into scope. And
what is taken into
scope in one module is not necessarily taken into scope in another
one, like with header
files (read the proposal, you'll see how this works)
>
>> 3.-
>> //Importing module std (package std in my wording)
>> import std;
>
>> //Now I can use vector or list without std::; because there
>> is an implicit using namespace std
>> //with the import statement.
>
There are very little probabilities of name clashes. You can still do
import std::vector
(assuming std is a folder and vector a module file). You JUST will get
symbols from the
std::vector module, not those which vector includes, because modules
do not get propagated
unless you make a public import inside vector. No name clashes, then.
After all, you can
still fully qualify a name to disambiguate.
> 1. if the namespace is very big named (including the nesting and such), but
> here a better option is a local shorter namespace alias
you will be able to do it. But... why would you? It's a better
solution the
other one, because most of the time you won't have to qualify every
name (less
verbosity)
> 2. if the namespace has not many "generic" names (std is the opposite,
> having alot of too general names such as "list", "vector", "pair" that have
> high chance of name clashes)
You won't have many chances of name clashes. You have that with
#includes, but
with modules, which have controlled exporting of symbols it is much
less likely to have
a clash.
>I supose which will bring all those general names I fear
You suppose a wrong thing. Because, again, when you import a module
all those general
names you refer won't get exported. Just the ones you expect them to
be there, no more,
no less.
> risky situations since includes may be added by someone else not realising
> they will bring the whole "std" names in the current scope)
This is exactly how modules DO NOT behave. Because modules do not
propagate another imports
unless a public import is done from the module you import. And that
would be a bad design
choice if you do a public import from things that are not public API.
> 4. if the names of the namespace that will be brought in current context are
> clearly known (and "std" again is the opposite since doing "using namespace
> std" may bring alot more than what you know as being the "public" std
> names, it may bring implementation specific names, thus a recipe for name
> clashes)
Same reason as above. Not likely.
> module decides to include something that indirectly will be included by
> your code and leading to the name clash?
This is not true for modules. Indirect includes is common in header
files, not in modules.
In modules you can say which symbols will be included. So the clashing
is much less likely.
Read the proposal, please. This is not the behaviour.
> That is the problem with "using namespace", the more you use it the more the
> risk of having name clash by unrelated changes, thus your code is
> not "stable" enough.
And modules is the solution to that problem :-)
An example:
//File std/vector.cpp
private:
//When module vector is imported, all symbols from privateimport are
not seen by the user of module vector.
import privateimport;
namespace std { namespace impl {
class vectorimpl { ... };
}
}
public:
//This import is done public, so public api from publiimport module is
exported when some user imports vector (and it's controlled by the
library writer)
import publicimport;
namespace std {
template
class vector {
...
};
}
//File mymodule.cpp
private:
import std::vector;
public:
namespace mymodule {
class MyClass {
vector v; //No need to qualify vector in mymodule. Implicit
using directive.
...
};
...
}
//File main.cpp
import mymodule; //This does not export the indirectly included
std::vector module, because std::vector is a private import inside
mymodule
import std::list;
//This could lead to ambiguous code. So you can fully qualify names or
alias names of std::list and something::list;
import something::list;
template using somelist = something::list;
int main()
{
vector v; //error, vector not included
MyClass mc; //Correct, because there is implicit using namespace
mymodule;
list l; //Ambiguous. You can write std::list or
something::list to disambiguate.
somelist l; //Correct. An alias has been used.
}
This way you avoid a lot of lines of unnecessary using directives and
still works pretty well. You
always have the option to fully qualify names to disambiguate. And
using directives just get applied to the modules
you directly import and for public imports that the module you import
has inside. No more. No name clashes (very few
chances). And you can use alias for commonly used symbols that could
clash anyway. This makes code shorted, almost for
sure. I would say much shorter than now.
{ Edits: quoted signature and clc++m banner removed. Please don't quote
extraneous material. -mod }
