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

[Walter Bright via Digitalmars-d]

On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> This is close. Forgive inaccurate syntax, but I see at least these issues that
> will make namespaces/module-system broken in terms of maintenance:
>
> YEAR 2014:
>
> framework1.d:
> extern (C++, std){ void something(); }
>
> framework2.d:
> extern (C++,std){void something(); void anything();}
>
> application.d:
> import framework1;
> import framework2;
> … std.something(); // is this ok, because the extern signatures match?

No. Even though they are the same function as far as the signatures are 
concerned, they are different functions as far as the D type system is 
concerned, and hence the call is ambiguous. You'll have to qualify by 
framework1.std.something() or framework2.std.something().



> std.d is updated:
> void something(){}
> void coolstuff(){}
>
> application.d is updated to use the new coolstuff():
> import framework1;
> import framework2;
> import.std();
> … std.something(); // namespace encapsulation broken or fail?
> … std.coolstuff();

No problem, std.d overrides because it is imported directly and so std is in the 
current scope. The current scope overrides imported scopes.


> application.d is corrected to (or using some other resolution):
> import framework1;
> import framework2;
> import.std();
> … framework2.std.something();
> … std.coolstuff();

Again, no problem.


> YEAR 2016:
>
> framework2.d is modified:
> extern (C++,std){ void anything(); }
>
> application.d is recompiled unmodified:
> import framework1;
> import framework2;
> import.std();
>   // fails even though the signature is still in framework1
> … framework2.std.something();

Still no problem. Qualifying it with framework2 says which one you want.

> … std.coolstuff();

Remember std is a symbol in the current scope.


> Right, but I want to be sure that the type-system sees all externs with the same
> signature as the same type.

Remember, a C++ signature is the same as its type in C++, but that is not true of D.


> I also am not sure how the "closing of namespaces"
> will work if you have multiple frameworks that independently specify their own
> C++ bindings to the same library.

D will regard those namespaces as completely separate and distinct scopes. The 
fact that C++ symbols in those separate scopes will mangle to the same symbol is 
up to the programmer to deal with - the same as with extern(C) symbols.


> The sole purpose of namespace/modules is to have clean separation between
> frameworks and support evolutionary development. I am not convinced that this
> property is not broken with the proposed change.
>
> To get around this you will have to remove the "closing of namespaces"
> restriction and add a root "cpp" so that all cpp namespaces get:
> cpp.std.something() etc…

I don't think there's anything needed to be gotten around here.