On Fri, 02 May 2014 01:22:12 +0100, deadalnix <deadalnix@gmail.com> wrote:

> 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.

#1 and #3 are essentially the same thing, and are how C# interfaces with .. well C, not C++ granted.  But, how does this make it impossible to port some C++ headers?

Were you thinking..

[a.cpp/h]
namespace a {
  void foo();
}

[b.cpp/h]
namespace b {
  void foo();
}

[header.h] <- header to import
#include "a.h"
#include "b.h"

[my.d]     <- our port
extern(c++, a) foo();
extern(c++, b) foo(); // oh, oh!

?

Because the solution is..

[a.d]
extern(c++, a) foo();

[b.d]
extern(c++, b) foo();

[my.d]
import a;
import b;

// resolve the conflict using the existing D mechanisms, or call them using a.foo, b.foo.

In essence we're re-defining the C++ namespace(s) as a D one(s) and we have complete flexibility about how we do it.  We can expose C++ symbols in any D namespace we like, we can hide/pack others away in a cpp or util namespace if we prefer.

R

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

On Thu, 01 May 2014 21:44:10 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> 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 :-)

Can you explain to people who don't understand DMD code, does this exactly implement the DIP? The two questions above imply that the DIP isn't enough to answer those questions...

-Steve

On Friday, 2 May 2014 at 09:25:34 UTC, Ola Fosheim Grøstad wrote:
> 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()

You are only proving that you are missing the point completely.

On Friday, 2 May 2014 at 17:34:49 UTC, deadalnix wrote:
>> framework_structname_function()
>
> You are only proving that you are missing the point completely.

Then I ask you to be graceful and explain it to me.

On 5/2/2014 6:53 AM, Steven Schveighoffer wrote:
> Can you explain to people who don't understand DMD code, does this exactly
> implement the DIP?

Yes.

> The two questions above imply that the DIP isn't enough to
> answer those questions...

It follows the scoping and name resolution rules used for template mixins.

On Fri, 02 May 2014 15:06:13 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/2/2014 6:53 AM, Steven Schveighoffer wrote:
>> Can you explain to people who don't understand DMD code, does this exactly
>> implement the DIP?
>
> Yes.
>
>> The two questions above imply that the DIP isn't enough to
>> answer those questions...
>
> It follows the scoping and name resolution rules used for template mixins.

OK, the questions (that I didn't understand) gave me the impression that you did something different from the DIP.

-Steve