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

On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:
> 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.

3. Use the C++ namespace for mangling, but not lookup.  C++ symbols will belong in the module they are imported into, and be treated exactly the same as a D symbol, e.g.

module a;
extern(C++, std) ..string..

module b;
extern(C++, std) ..string..

module c;
import a;
import b;

void main() { .. string .. }   // error could be a.string or b.string
void main() { .. a.string .. } // resolved

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 01 May 2014 11:03:21 +0100, Regan Heath <regan@netmail.co.nz> wrote:

> On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> 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.
>
> 3. Use the C++ namespace for mangling, but not lookup.  C++ symbols will belong in the module they are imported into, and be treated exactly the same as a D symbol, e.g.
>
> module a;
> extern(C++, std) ..string..
>
> module b;
> extern(C++, std) ..string..
>
> module c;
> import a;
> import b;
>
> void main() { .. string .. }   // error could be a.string or b.string
> void main() { .. a.string .. } // resolved

Sorry, #1 is the same suggestion :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 4/27/2014 12:54 PM, Walter Bright wrote:
> http://wiki.dlang.org/DIP61

Now with pull request: https://github.com/D-Programming-Language/dmd/pull/3517

On Thursday, 1 May 2014 at 10:03:21 UTC, Regan Heath wrote:
> On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> 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.
>
> 3. Use the C++ namespace for mangling, but not lookup.  C++ symbols will belong in the module they are imported into, and be treated exactly the same as a D symbol, e.g.
>

1. The whole point of C++ namespace is to avoid that. That is going to happen. Probably less in D as we have module scoping. But that makes it impossible to port many C++ headers.

2. Creating a new name lookup mechanism is the kind of idea that sound good but ends up horribly backfiring. There is all kind of implications and it affect every single identifier resolution. You don't want to mess with that (especially since it is already quite badly defined in the first place).

3. That makes it impossible to port some C++ headers just as 1.

On Thursday, 1 May 2014 at 18:44:36 UTC, Walter Bright wrote:
> On 4/27/2014 12:54 PM, Walter Bright wrote:
>> http://wiki.dlang.org/DIP61
>
> Now with pull request: https://github.com/D-Programming-Language/dmd/pull/3517

Does that create a new named scope ? And regular D identifier resolution rule ? IF yes, that's awesome news !

On 5/1/2014 5:33 PM, deadalnix wrote:
> On Thursday, 1 May 2014 at 18:44:36 UTC, Walter Bright wrote:
>> On 4/27/2014 12:54 PM, Walter Bright wrote:
>>> http://wiki.dlang.org/DIP61
>>
>> Now with pull request: https://github.com/D-Programming-Language/dmd/pull/3517
>
> Does that create a new named scope ?

Yes.

> And regular D identifier resolution rule ?

Yes.

> IF yes, that's awesome news !

I am rather pleased with how it turned out :-)

On Friday, 2 May 2014 at 00:22:14 UTC, deadalnix wrote:
> 2. Creating a new name lookup mechanism is the kind of idea that sound good but ends up horribly backfiring. There is all kind of implications and it affect every single identifier resolution. You don't want to mess with that (especially since it is already quite badly defined in the first place).

What implications?

The implications with this DIP is that all library authors will have to follow a convention of having all C++ dependencies in a module named "cpp" in order to have a "fake" way of specifying fully qualified C++ names.

Then lobby for coercing C++ types that have different paths.

This is not elegant. It is a hack.

On 5/2/2014 12:34 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> The implications with this DIP is that all library authors will have to follow a
> convention of having all C++ dependencies in a module named "cpp" in order to
> have a "fake" way of specifying fully qualified C++ names.

Not at all, any more than you have to do that for C names.


> This is not elegant. It is a hack.

C++ is not elegant, and interfacing to it will necessarily pick up some of that.

On Friday, 2 May 2014 at 07:44:50 UTC, Walter Bright wrote:
> Not at all, any more than you have to do that for C names.

The difference is that C names tend to have their namespace embedded:

framework_structname_function()