german diago wrote:
>
>> 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.
But that's not the point. I am using unqualified names for local names and
having import do "using namespace" would create the potention of conflict.
I would like to have the choice between doing using namespace and not doing
it as we have it today with include.
> 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)
As I described bellow "using namespace" is not a solution for anything when
importing unknown, many, potentially conflicting names in popular headers
(and you proved that modules reduce the ammount of unknown exposed names
but they do not remove it completely so there's a problem).
>
> 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.
If you assume there will be a module for every possible name from the std
namespace, that's too much isn't it? "vector" is a good example for your
sugestion but I find another, not so good, "utility". How do you control
which names it brings and which doesn't? or "algorithm" (like I want to
have my sort and use it with "sort" without possible nameclash with
std::sort for which I qualify so there is no name clash).
In general in my code when I refer to my own types I use unqualified names
(since they are in the current namespace of my code anyway) and when I
refer to whatever library types I qualify them (which makes sense since
they are external and out of my direct control). Your sugestion would make
it have to qualify internal names too since possible name clashes from
bringing library names into the local context. And I really don't see how
code would look any way better when one would have things like:
namespace mycode {
void MyClass::func(mycode::SomeType arg) {}
}
instead of the simple and more direct:
namespace mycode {
void MyClass::func(SomeType arg) {}
}
(since SomeType is in the same namespace as "mycode" it makes sense not to
require qualification)
> After all, you can
> still fully qualify a name to disambiguate.
But I do not want to be forced to do this for local code. One big advantage
IMO of C++ namespaces in general is that they find unqualified names
without qualification if you are in a namespace context and that
unqualified name is in that context, which follows a natural design of the
code. That is, I have a project which has everything in the
namespace "project" and does use boost and std. Thus, when I refer to my
own names I do not need to qualify them since the code is too in the same
namespace and it will find unqualified names in the same namespace. When I
need to refer to library names I always qualify them since I do not have
direct control over their names (someone else maintains that library code
so I need to make sure I don't create name clashes just upgrading a version
of the library code).
>
>> 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.
What about "algorithm", "utility" and other modules which may bring more
than a single name?
>>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.
How can you specify that importing "algorithm" you expect
only "std::transform" to be brought in the current namespace?
> 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.
Ok, that is a good thing about modules. But still doesn't provide the per
name control I want, plus I almost never refer to library names unqualified
(but I do to my own names).
>> 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.
> ...
> };
> ...
> }
This still forces me to qualify local names which normally I don't. Also it
does not fix the situation of modules with many names (vector is not such a
module as you describe).
> 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.
>From what I understand I don't have this option anymore, you force me to
qualify for my own names to avoid possible name clashes from automatic
using namespace of public module names.
