DIP61: redone to do extern(C++,N) syntax

[Timon Gehr via Digitalmars-d]

On 04/30/2014 02:41 AM, Steven Schveighoffer wrote:
> On Tue, 29 Apr 2014 17:38:07 -0400, Timon Gehr <timon.gehr at gmx.ch> 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;