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.

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.

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.

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.

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.

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

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?

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