Is there any good reason why C++ namespaces are "closed" in D?

Steven Schveighoffer schveiguy at gmail.com
Thu Aug 2 12:13:18 UTC 2018


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


More information about the Digitalmars-d mailing list