On 04/30/2014 02:41 AM, Steven Schveighoffer wrote:
On Tue, 29 Apr 2014 17:38:07 -0400, Timon Gehr <[email protected]> wrote:
...
Maybe he didn't notice that you changed the 'main' function relative
to my post. If you don't mention 'foo' explicitly, then obviously it
cannot be hidden by the import and the code is in error.
I never changed the code. It always was foo.func(). That was my point.
...
(What I mean is that in the post you were answering, main just contained
'foo'.)
I think you guys need to reexamine this,
Not me. I typically test my claims even if I am sure, if only to file
bug reports.
Your view has been consistent. I think it defeats the purpose of having
namespaces to disambiguate calls, since the disambiguation itself
conflicts with modules.
If foo.func means one thing today and another thing tomorrow, based on
an import, I think the feature is flawed. Template namespaces are just
as flawed.
and choose one way or another.
At this point, I have no clue as to how it's supposed to work.
Obviously you did not actually try. :P
No, I get what you are saying. The above statement is because I'm
getting conflicting reports from Walter.
...
Ok, apologies.
...
module foo;
import std.stdio;
int func(){ writeln("hello from foo!"); return 1; }
//---
module bar;
import std.stdio;
mixin template X(){
int func(){ writeln("hello from bar!"); return 2; }
}
mixin X foo;
//---
module prog;
void main(){
void onlybar(){
import bar;
auto r=foo.func(); // hello from bar!
assert(r==2); // pass!
}
void fooandbar(){
import bar,foo;
auto r=foo.func(); // hello from foo!
assert(r==1); // pass!
}
onlybar();
fooandbar();
}
Wouldn't a similar test be to create a struct for a namespace?
...
Yes, and this behaves the same in this specific case.
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.
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 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.
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;
