On Wed, 30 Apr 2014 15:56:15 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:
On 04/30/2014 02:41 AM, Steven Schveighoffer wrote:
Wouldn't a similar test be to create a struct for a namespace?
...
Yes, and this behaves the same in this specific case.
Just a note of friendly advice, most people understand using struct/class
as a namespace than mixing in a template (including myself).
The confusing issue here to C++ programmers is, when I specify x::y::z,
it means z in namespace x::y, regardless of where it was imported. If in
D we say you can access this via x.y.z, they are going to think they can
always type that. To have it so easily break is not a good thing.
...
If this is a problem, I guess the most obvious alternatives are to:
1. Get rid of namespace scopes. Require workarounds in the case of
conflicting definitions in different namespaces in the same file. (Eg.
use a mixin template.) I'd presume this would not happen often.
You mean use the syntax just to give mangling info? I think that would be
OK.
Another option I thought of is to alias the symbol before exiting the
namespace scope (and still disallow namespace lookup):
extern(C++, std){
class string {...}
alias std_string = string; // std_string not likely to be in conflict.
}
std.string would not refer to string above, ever.
I think it would be useful to be able to specify an alias in one line also:
extern(C++, std) alias std_string = string;
Of course, such a system does not scale well, but it would fit within D's
lookup rules.
2. Give the global C++ namespace a distinctive name and put all other
C++ namespaces below it. This way fully qualified name lookup will be
reliable.
This was my suggestion as well.
This is because the import of module 'foo' hides the namespace 'foo'
imported from 'bar' in the scope of 'fooandbar'. It is not 'func' that
is being hidden, but 'foo'.
In fact, it's the entire foo namespace.
...
Yes, but this is visible in the file that is being changed.
We have supposedly told C++ developers "if your C++ symbol is ambiguous,
disambiguate using the namespace." This won't always work, and the result
is going to be ugly and super-confusing.
So basically any namespace that matches the root phobos import path will
cause conflicts. You don't suppose any C++ code uses that do you? ;)
How many C++ standard headers contain conflicting symbol names in
different namespaces? If the namespace symbol really needs to be
addressable, there could be an alias. eg. alias cpp=std;
There probably are few that contain competing names. I'm more concerned
about namespaces that D has copied from C++. Many in std.algorithm,
std.string, etc. Using C++ namespace std is going to result in quite a bit
of confusion and conflict I think.
-Steve
