On 8/1/18 7:04 PM, Walter Bright wrote:
On 8/1/2018 10:24 AM, Jonathan M Davis wrote:
Not to say that that can't work, but I have to say that it seems
pretty ugly
if using extern(C++, NS) requires a bunch of aliases just to use symbols
normally.
What is normal is a slippery concept, especially when one is comparing
different lookup rules between languages. D modules do not a 1:1
correspondence with C++ namespaces, either (not even close).
Aliases are a normal and highly useful D tool to copy names from one
scope to another.
Certainly, it does come across like
you didn't trust the D module system to do its job for some reason.
Reorganizing the code into modules means potentially forcing users to
split code from one C++ file into multiple D files. How's that really
going to work if you have a translation tool? One of the aspects of Java
I didn't care for was forcing each class into its own file.
So while Manu is clearly happy with cutting up a C++ file into multiple
D files, I doubt that is universal. His proposal would pretty much
require that for anyone trying to work with C++ namespaces who ever has
a name collision/hijack or wants to make the code robust against
collision/hijacking.
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:
int a[10];
for (int i = 0; i <= 10; ++i)
...a[i]...
But we both know they do just often enough for it to be a disaster.
I challenge you to find any C++ code that has two identical function
names in the same header file, but in different namespaces. I've done
C++ development, but not really a C++ developer since about 2010 or so,
but to me, this sounds like utter stupidity to do that. I think most of
the issue with name conflict is between different *projects*, which is
why you have a namespace to begin with.
In other words, libfoo defines foo, and libbar defines foo (how dare
they!) and now there is a conflict, but you can distinguish by using
foo::foo, and bar::foo. But it would be no different in D, since they
would be in different libraries anyway, not in the same module.
I think comparing that to the <= problem is like apples and oranges.
While the problem you identify *is* a problem, I believe it only exists
on this thread, and not anywhere else.
-Steve
