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

[Regan Heath via Digitalmars-d]

On Fri, 02 May 2014 01:22:12 +0100, deadalnix <deadalnix at 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 at 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/