DIP61: redone to do extern(C++,N) syntax

Byron via Digitalmars-d digitalmars-d at puremagic.com
Mon Apr 28 08:09:38 PDT 2014


On Mon, 28 Apr 2014 10:54:17 -0400, Steven Schveighoffer wrote:

>>>
>>> That doesn't help. foo.func() is still ambiguous. With this proposal,
>>> you have hijacked the meaning of namespace lookup. When I say x.y.z,
>>> it doesn't just mean look for symbol z in module x/y.d, it can also
>>> mean to look for symbol z in C++ namespace x::y. This was not the case
>>> with C binding, which continued to use D modules for symbol lookup.
>>>
>>> Consider that a boatload of C++ code is named std::something. Now,
>>> std.string has an ambiguous meaning wherever it is used!
>>>
>>> -Steve
>>
>> bar is renamed, thus you have to access via _cpp.[namespace] renames
>> were added to prevent hijacking.
> 
> That renames the bar module, but not the foo C++ namespace, which can be
> assumed when calling foo.func.
> 
> In reality, you could "fix" the situation by renaming the foo D module,
> and then foo.func would unambiguously refer to bar's func :)
> 
> Another alternative fix would be to allow renaming C++ namespaces. I
> strongly recommend against that. The better alternative is to reserve
> qualified name lookup to D modules alone. Adding a mechanism that is
> possibly ugly, but that does NOT conflict with module lookup, in order
> to disambiguate C++ symbols is fine.
> 
> -Steve



I am confused now, cross module renaming??

I was thinking this:

a.d
extern(C++, std) {  ... class string ... }


b.d
import std.string;
import cpp = a; // a must be accessed via cpp

std.string.... /// okay D version
cpp.std.string ... /// okay c++ version
string ... /// Okay D version
cpp.string /// Okay C++ version






More information about the Digitalmars-d mailing list