On 12/07/2015 10:08 p.m., Jacob Carlborg wrote:
> On 2015-07-12 05:46, Rikki Cattermole wrote:
>
>> Good job woot!
>> Now we just need a way to create instances ext. :)
>
> You can create instances with the help of the Objective-C runtime, have
> a look at one of the tests [1].
>
> [1]
> https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/objc_call.d

For the release this goes into I'll definitely have to try and port it then!

On Saturday, 11 July 2015 at 20:25:47 UTC, Jacob Carlborg wrote:
> [1] https://github.com/D-Programming-Language/dmd/commit/941808dc44a03396d41657cfa9ccc8bfe901f3a7
>
> [2] https://github.com/D-Programming-Language/druntime/commit/b50096fdbe425e32b4edf1341369434a57a63b31

Cool! I'll spread the word to all my D-friends :)

On Sunday, 12 July 2015 at 10:07:36 UTC, Jacob Carlborg wrote:
> On 2015-07-11 23:18, Jack Stouffer wrote:
>
>> Is there any documentation available yet?
>
> No, no official documentation. You can have a look at the DIP [1], but that contains a lot more than what's currently implemented. I recommend having a look at the tests, this one [2] for example.
>
> [1] http://wiki.dlang.org/DIP43
> [2] https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/objc_call.d

Cool, thanks :)!

Is this going to make the 2.068 cut?

On 7/11/15 4:25 PM, Jacob Carlborg wrote:
> I just manged to get all tests passing on all platforms. Now the first
> step of D/Objective-C has been merged [1][2]. The only thing that's
> supported for now is calling Objective-C instance methods from D.
>
> I want to give special thanks to Michel Fortin who did the original
> implementation. I also want to thank Walter, Daniel and all others who
> reviewed the code.
>
> Thank you.
>
> [1]
> https://github.com/D-Programming-Language/dmd/commit/941808dc44a03396d41657cfa9ccc8bfe901f3a7
>
>
> [2]
> https://github.com/D-Programming-Language/druntime/commit/b50096fdbe425e32b4edf1341369434a57a63b31

Very nice!

I wanted to ask, swift can call into objective-C, so does this de-facto give us a D/swift binding as well? I haven't written a single line of swift yet, so apologies if this is a stupid question.

-Steve

On 2015-07-12 19:33, Jack Stouffer wrote:

> Cool, thanks :)!
>
> Is this going to make the 2.068 cut?

The release manager will need to answer this.

-- 
/Jacob Carlborg

On 2015-07-13 16:02, Steven Schveighoffer wrote:

> I wanted to ask, swift can call into objective-C, so does this de-facto
> give us a D/swift binding as well? I haven't written a single line of
> swift yet, so apologies if this is a stupid question.

Without having tried it I would say it works. Of course only what Objective-C has access to. There are a couple of Swift specific features that Objective-C cannot access.

-- 
/Jacob Carlborg

On 2015-07-13 14:02:54 +0000, Steven Schveighoffer <schveiguy@yahoo.com> said:

> I wanted to ask, swift can call into objective-C, so does this de-facto give us a D/swift binding as well? I haven't written a single line of swift yet, so apologies if this is a stupid question.

More or less. If you define an `extern (Objective-C)` class in D (once all my work is merged), you can use it and derive from it in Swift. If you define an `@objc` class in Swift you can use it from Objective-C and from D, but you can't derive from it.

Note that the Swift ABI isn't stable yet. So the above might change at some point.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 2015-07-14 03:11, Michel Fortin wrote:

> More or less. If you define an `extern (Objective-C)` class in D (once
> all my work is merged), you can use it and derive from it in Swift. If
> you define an `@objc` class in Swift you can use it from Objective-C and
> from D, but you can't derive from it.

Do you know why you can't derive from it?

> Note that the Swift ABI isn't stable yet. So the above might change at
> some point.

But they need to follow the Objective-C ABI, for the @objc classes. I guess they technically can change the Objective-C ABI if they want to.

-- 
/Jacob Carlborg

On 2015-07-14 13:59:51 +0000, Jacob Carlborg <doob@me.com> said:

> On 2015-07-14 03:11, Michel Fortin wrote:
> 
>> More or less. If you define an `extern (Objective-C)` class in D (once
>> all my work is merged), you can use it and derive from it in Swift. If
>> you define an `@objc` class in Swift you can use it from Objective-C and
>> from D, but you can't derive from it.
> 
> Do you know why you can't derive from it?

I'm not sure. Apple's documentation says: "You cannot subclass a Swift class in Objective-C." I assume there could be a variety of reasons, such as more aggressive optimizations.


>> Note that the Swift ABI isn't stable yet. So the above might change at
>> some point.
> 
> But they need to follow the Objective-C ABI, for the @objc classes. I guess they technically can change the Objective-C ABI if they want to.

Actually, they only need to follow it up what they guaranty will work. If you debug some Swift code mixed with Objective-C, you'll notice that every call to a Swift method from Objective-C first passes through a thunk function (not dissimilar to my first D/Objective-C bridge made using D template mixins). Now, suppose you override this function from the Objective-C side, only the thunk gets overriden and Swift calles and Objective-C callers will no longer call the same function.

I haven't verified anything, but that's my theory.


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 2015-07-14 20:05, Michel Fortin wrote:

> Actually, they only need to follow it up what they guaranty will work.
> If you debug some Swift code mixed with Objective-C, you'll notice that
> every call to a Swift method from Objective-C first passes through a
> thunk function (not dissimilar to my first D/Objective-C bridge made
> using D template mixins). Now, suppose you override this function from
> the Objective-C side, only the thunk gets overriden and Swift calles and
> Objective-C callers will no longer call the same function.
>
> I haven't verified anything, but that's my theory.

Hmm, I see. I imagined something similar would need to be done for the new exception handling in Swift 2, but for every method, that was unexpected.

Now when Swift goes open source someone can just have a look and see what's going on :)

-- 
/Jacob Carlborg