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

[Regan Heath via Digitalmars-d]

On Wed, 30 Apr 2014 05:03:58 +0100, Ola Fosheim Grøstad  
<ola.fosheim.grostad+dlang at gmail.com> wrote:
> Wrong KISS: compiler internals over specification

Indeed.

I've been a C/C++ developer for ~16 years and I was confused several times  
reading this thread.

The mix of D modules and C++ namespaces is the thing what needs to be kept  
simple for us lesser mortals, not the compiler implementation - which  
should, I agree, *ideally* remain simple, but in this case should be  
sacrificed for the other because compiler writers are good at what they do  
and will be able to cope.

I think it is simpler all round to just invent (and perhaps reserve) a new  
top level module for C++ namespaces (an idea mentioned here already) i.e.  
"cpp"

Example:

module a;
extern(C++, std) class string {..} // identical to decl in b

module b:
extern(C++, std) class string {..} // identical to decl in a
extern(C++, std) class vector {..} // new decl

module userland;
import a;
import b;

void main()
{
   cpp.std.string x = new cpp.std.string();
   cpp.std.vector y = new cpp.std.vector();
}

Notes:
  - the D modules 'a' and 'b' play no part whatsoever in the lookup of the  
C++ symbol (why the hell should they? I see no benefit to this)
  - the identical declarations in a/b for std.string are treated as one.
  - any *use* (in userland) of a non-identical/ambiguous declaration would  
result in an error.

Link time is where it would actually complain if multiple C++ symbols were  
found.

Special lookup rules would apply to cpp.*

My 2p/c

R

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