<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 3 January 2016 at 15:45, Walter Bright via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 1/2/2016 9:19 PM, Manu via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In addition to that rant, extern(C++) seems to fail at forward referencing. Any<br>
time I have 2 modules that refer to eachother, suddenly the order of everything<br>
is critical. I can sometimes resolve these problems by moving imports out of the<br>
global scope, but often it's terminal, and I need to restructure everything in<br>
awkward and unnatural ways to break the stalemate.<br>
<br>
I know I'll just get complaints from people to submit bugs; I have submit lots,<br>
and in many cases, I've tried to, but they're almost impossible to produce in<br>
isolation, only when a project gets 'real', ie, big enough that it's realistic<br>
in scope does it all start to break down. It's really hard to reduce a bug that<br>
I don't understand, somewhere among a program with 30-ish interconnected<br>
modules. It's worse when the structure of the project is unnatural, a<br>
requirement forced by the namespace issue, and everything is already really<br>
brittle as a result.<br>
<br>
The thing is, it almost all comes back to the pseudo-namespaces (sprinkled with<br>
weird forward referencing issues). Maybe it sounded good at the time, but it<br>
doesn't work in practice. If that was fixed, then we'd stand on solid ground,<br>
and it might be possible to reduce bugs and move forward in that environment.<br>
</blockquote>
<br></span>
They're not pseudo-namespaces. C++ namespaces in D are scoped namespaces and follow all the D scoping and name lookup rules. They are mangled, however, like C++ namespace scoped symbols are mangled.<br></blockquote><div><br></div><div>I don't want that. That's what modules are for.</div><div>extern(C++) should only state where the external C++ function is to be found. If the user wants the D symbol under a namespace to match C++, let them do so explicitly. But they probably already are via the module scope.</div><div><br></div><div>Given a C++ symbol 'NS::CSymbol', the D symbol 'x.y.NS.CSymbol' bears no meaningful relation. D still prefixes the module scope.</div><div><br></div><div>The user will almost certainly instead do:</div><div><br></div><div>module NS; // a module for the C++ thing</div><div>extern(C++, NS) void func();</div><div><br></div><div>Which would give them the symbol 'NS.NS.func'. Surely what they intended was 'NS.func' to match the C++ symbol?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I am not aware of any forward reference issues with C++ namespaces, so without an example, I cannot do anything.<br>
</blockquote></div><br></div><div class="gmail_extra"><a href="https://issues.dlang.org/show_bug.cgi?id=15389">https://issues.dlang.org/show_bug.cgi?id=15389</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Over a month ago, nearer to the start of my descent into madness. I suspect this had lead to some mis-diagnoses of issues.</div></div>