On Thursday, 2 August 2018 at 04:59:52 UTC, Walter Bright wrote:
On 8/1/2018 7:09 PM, Rubn wrote:
On Wednesday, 1 August 2018 at 23:04:01 UTC, Walter Bright
wrote:
An example of silent hijacking:
extern (C++, "ab") void foo(long); // original code
... lots of code ...
extern (C++, "cd") void foo(int); // added later by
intern, should have been
// placed in another
module
... a thousand lines later ...
foo(0); // OOPS! now calling cd.foo() rather than
ab.foo(), D sux
You might say "nobody would ever write code like that." But
that's like the C folks saying real C programmers won't write:
You can do that today, just remove the "extern(C++, ...)" part
and you have the same issue. Why should C++ with namespaces be
safer than just regular D ? I don't understand, if it is such
a huge gigantic problem why didn't you do anything to solve
this problem in regards to D then ?
The difference is those names are supposedly in different
namespaces, given that the code is converted from C++:
namespace ab { void foo(long); }
... lots of code ...
namespace cd { void foo(int); }
where the foo()'s do not conflict with each other, and a user
would reasonably expect that same behavior when translated to D.
If you *want* them in the same scope in D, you can do that with
alias.
You can say the same thing in D. If you have "module ab" and
"module cd", if you put the function in the wrong file, you will
face this same bug. It's not a hypothetical, it's the current
implementation in D, yet no one has complained or filed a bug
report about it.
The bug is caused by the implicit conversion from int to long.
That is not, nor should it be, the purpose of C++ namespaces in D
to fix.
