www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP87: Enhanced Foreign-Language Binding

reply Anon <anon anon.anon> writes:
Seeing the recent extern(C++) threads, and much concern therein, 
I'd like to propose DIP87: http://wiki.dlang.org/DIP87

Destroy to your heart's content.
Jan 20 2016
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 21/01/16 5:21 PM, Anon wrote:

 Seeing the recent extern(C++) threads, and much concern therein, I'd
 like to propose DIP87: http://wiki.dlang.org/DIP87

 Destroy to your heart's content.


It was great until I saw:
extern(auto, "myMoveTo:")

After all:
extern(C/C++/D/Objective-C[, string])

Is that string meant for raw mangling or effect mangling in the form of 
selector?

Just no, leave  selector alone I think.

You have the same problem with c++ namespaces.

Perhaps this is slightly wrong.
extern(string)
Is the only way to force a specific mangling.

Where as
extern(C/C++/D/Objective-C[, string])
with the string altering in C++ and Objective-C mode.

So the only difference is extern(string) vs pragma(mangle, string)
Little harder sell, but I think might be worth it for cleaning up the 
language.
Jan 20 2016
parent reply Anon <anon anon.anon> writes:
On Thursday, 21 January 2016 at 04:42:00 UTC, Rikki Cattermole 
wrote:

 On 21/01/16 5:21 PM, Anon wrote:

 Seeing the recent extern(C++) threads, and much concern 
 therein, I'd
 like to propose DIP87: http://wiki.dlang.org/DIP87

 Destroy to your heart's content.


 It was great until I saw:
 extern(auto, "myMoveTo:")

 After all:
 extern(C/C++/D/Objective-C[, string])

 Is that string meant for raw mangling or effect mangling in the 
 form of selector?

 Just no, leave  selector alone I think.


I don't know ObjC, so I had to wing it on the details there. The 
strings in
extern(<Foo>, "str") would get sent through Foo's mangler. For 
ObjC, I currently imagine those strings forming the selector, 
much the same way it is specified through  selector. That ObjC's 
mangling mostly consists of 's/:/_/g' is irrelevant. I want *all* 
language binding to happen with a uniform interface. No more 
one-off hacks for a particular language (which is exactly what 
extern(C++,ns) and  selector are).



 You have the same problem with c++ namespaces.


I don't see a problem. You'll have to be more specific.



 Perhaps this is slightly wrong.
 extern(string)
 Is the only way to force a specific mangling.


There is no extern(string) in this proposal, nor is there a way 
to force a specific mangling, which (AFAIK) was only introduced 
to allow linking to C symbols that happened to be keywords.



 Where as extern(C/C++/D/Objective-C[, string])
 with the string altering in C++ and Objective-C mode.


It mangles regardless. Any and all of the extern(<Foo>) modes 
mangle. That C's mangling is to just return the input string is 
irrelevant.



 So the only difference is extern(string) vs pragma(mangle, 
 string)
 Little harder sell, but I think might be worth it for cleaning 
 up the language.


The difference is that it can mangle symbols correctly, even if 
the symbol is a D keyword.

Currently:

extern(C++) pragma(mangle, "delegate") int delegate_();

...yields a mangled name of "delegate", and there is no way to 
get the compiler to mangle the symbol correctly. Meaning you have 
to (ab)use pragma(mangle) and provide it with the full mangled 
name yourself. And `version()` it appropriately to deal with 
gcc/clang vs MSVC/DMC mangling.

With this DIP:

extern(C++, "delegate") int delegate_();

... would yield a mangled name of "_Z8delegatev" (or similar).

I thought I did a good enough job of explaining that in the DIP 
so I wouldn't have to here.
Jan 20 2016
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 21/01/16 6:46 PM, Anon wrote:
snip


 I thought I did a good enough job of explaining that in the DIP so I
 wouldn't have to here.


I was trying to explain some better semantics because how it is 
currently with strings can be and is a bit ambiguous.
Jan 20 2016
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 21 January 2016 at 04:21:06 UTC, Anon wrote:

 Seeing the recent extern(C++) threads, and much concern 
 therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87

 Destroy to your heart's content.


This propose to change everything while not even providing 
anything more than what we already have.

If it was to start from scratch, why not, but clearly, in its 
current shape, this doesn't pay for itself.
Jan 20 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-21 05:21, Anon wrote:

 Seeing the recent extern(C++) threads, and much concern therein, I'd
 like to propose DIP87: http://wiki.dlang.org/DIP87

 Destroy to your heart's content.


* How do you plan to differentiate specifying the namespace compared 
with specifying the mangled name for an extern(C++) symbol?

* For Objective-C bindings one needs to be able to specify the mangled 
name for a class or interface without affecting the names of the 
methods. It's required because in Objective-C it's possible to have the 
same name for a class and a protocol (interface). In the Foundation 
framework (standard library) there are a class "Object" and a protocol 
"Object"

* When creating Objective-C bindings it's basically required to specify 
the selector for every method

* In Objective-C the mangled name and the selector is not the same. The 
mangled name is for the linker to find the correct symbol. The selector 
is for finding the correct method implementation at runtime

-- 
/Jacob Carlborg
Jan 22 2016
parent reply Anon <anon anon.anon> writes:
On Friday, 22 January 2016 at 16:37:31 UTC, Jacob Carlborg wrote:

 On 2016-01-21 05:21, Anon wrote:

 Seeing the recent extern(C++) threads, and much concern 
 therein, I'd
 like to propose DIP87: http://wiki.dlang.org/DIP87

 Destroy to your heart's content.


 * How do you plan to differentiate specifying the namespace 
 compared with specifying the mangled name for an extern(C++) 
 symbol?


Ideally, by whether the `extern()` forms a block or it is 
attached directly to the symbol. I understand that wouldn't work 
with existing implementation in the compiler, but hopefully it 
wouldn't be too difficult to do. But I know nothing of compiler 
internals so am probably wrong.


 * For Objective-C bindings one needs to be able to specify the 
 mangled name for a class or interface without affecting the 
 names of the methods. It's required because in Objective-C it's 
 possible to have the same name for a class and a protocol 
 (interface). In the Foundation framework (standard library) 
 there are a class "Object" and a protocol "Object"


I'll have to look into this more. My cursory reading told me of 
"instance" methods and "class" methods, that get mangled as 
"_i_<Something>_<method>..." and "_c_<Something>_<method>..." 
respectively. Is this what you are talking about?


 * When creating Objective-C bindings it's basically required to 
 specify the selector for every method


I know, because of the parameter names being part of the API (and 
mangled name). I still think the approach described in the DIP 
should be workable.


 * In Objective-C the mangled name and the selector is not the 
 same. The mangled name is for the linker to find the correct 
 symbol. The selector is for finding the correct method 
 implementation at runtime


Sure, but when using ObjC code from D:

extern(Objective-C) class Something {
void moveTo(float x, float y)  selector("x:y:");
}

// Elsewhere
something.moveTo(1,2);

I don't see how the selector is doing anything more than mangling 
here. Even if you have multiple methods in D that mangle to the 
method name in ObjC (minus parameters), that selection is done by 
D, which then mangles the name according to the selector, right? 
If not, do you have an example handy to illustrate?
Jan 22 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-23 02:31, Anon wrote:


 Ideally, by whether the `extern()` forms a block or it is attached
 directly to the symbol. I understand that wouldn't work with existing
 implementation in the compiler, but hopefully it wouldn't be too
 difficult to do. But I know nothing of compiler internals so am probably
 wrong.


That will change the behavior compared to how all other attributes work. 
There's no difference for these syntaxes:

extern(C) int a;
extern(C) { int a; }
extern(C): int a;

Or:

public int a;
public { int a; }
public: int a;


 I'll have to look into this more. My cursory reading told me of
 "instance" methods and "class" methods, that get mangled as
 "_i_<Something>_<method>..." and "_c_<Something>_<method>..."
 respectively. Is this what you are talking about?


No. In Objective-C there's a protocol (interface) called "NSObject" and 
a class called "NSObject". It needs to be possible to do this:

extern(Objective-C)
class NSObject {} // standard mangling, NSObject

extern(Objective-C) pragma(mangle, "NSObject")
interface NSObjectProtocol {} // custom mangling, NSObject

The mangling for a method is more like L_OBJC_SELECTOR_REFERENCES_0. 
Where 0 is an increasing number.

If you have access to a Mac you can try compiling this [1] example and 
list all symbols with the "nm" command.


 Sure, but when using ObjC code from D:

 extern(Objective-C) class Something {
 void moveTo(float x, float y)  selector("x:y:");
 }

 // Elsewhere
 something.moveTo(1,2);

 I don't see how the selector is doing anything more than mangling here.
 Even if you have multiple methods in D that mangle to the method name in
 ObjC (minus parameters), that selection is done by D, which then mangles
 the name according to the selector, right? If not, do you have an
 example handy to illustrate?


No. The above call to "moveTo" is lowered to something like this:

objc_msgSend(something, "x:y:", 1, 2);

The Objective-C runtime will find the correct method implementation to 
call based on the selector.

[1] http://dlang.org/spec/objc_interface.html#usage-example

-- 
/Jacob Carlborg
Jan 23 2016