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

[Steven Schveighoffer via Digitalmars-d]

On Wed, 30 Apr 2014 15:56:15 -0400, Timon Gehr <timon.gehr at 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