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
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
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
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
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
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
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
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