On Wed, 30 Apr 2014 05:03:58 +0100, Ola Fosheim Grøstad
<ola.fosheim.grostad+dl...@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/
