www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D/Objective-C, extern (Objective-C)

reply Jacob Carlborg <doob me.com> writes:
As some of you might know Michel Fortin created a fork of DMD a couple 
of years ago which add support for using Objective-C classes and calling 
Objective-C method. That is making D ABI compatible with Objective-C.

I have now updated it to the latest version of DMD and druntime. All 
D/Objective-C tests pass and all standard tests pass. I'm planning to 
create a DIP for this and would really like this to be folded into main 
line. For know you can read the design document created by Michel:

http://michelf.ca/projects/d-objc/syntax/

Original project page: http://michelf.ca/projects/d-objc/

My forks:
DMD: https://github.com/jacob-carlborg/dmd/tree/d-objc
druntime: https://github.com/jacob-carlborg/druntime/tree/d-objc
Phobos: standard Phobos, commit f85bd54ef5615986960fdd68ea87c8aaf5c5118d

Currently I have limited bandwidth and cannot upload a pre-compiled 
binary. To compile use the following commands:

cd dmd/src
make -f posix.mak MODEL=32 D_OBJC=1

cd druntime
make -f posix.mak DMD=../dmd/src/dmd MODEL=32 D_OBJC=1

cd phobos
make -f posix.mak DMD=../dmd/src/dmd MODEL=32

Currently D/Objc only works for 32bit. You can use Michel's example 
application, Chocolate, to try it out. It's a bit cumbersome to compile 
without Xcode but it's possible.

http://littoral.michelf.ca/code/d-objc/chocolate-dobjc-a1.zip

-- 
/Jacob Carlborg
Jun 23 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 http://michelf.ca/projects/d-objc/syntax/


Instead of:
extern (Objective-C)

Is it better to use a naming more D-idiomatic?

extern (Objective_C)


Regarding this syntax:

void insertItem(ObjcObject object, NSInteger value) 
[insertItemWithObjectValue:atIndex:];

Is it possible and good to replace it with some UDA?



 I'm planning to create a DIP for this and would really like 
 this to be folded into main line.


It seems contain some different things/syntax. I don't know how 
much Walter&Co will appreciate it.

Bye,
bearophile
Jun 23 2013
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-06-23, 23:02, bearophile wrote:


 Jacob Carlborg:


 http://michelf.ca/projects/d-objc/syntax/


 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)


There's already some precedence in extern (C++).

-- 
Simen
Jun 23 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-23 23:02, bearophile wrote:


 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)


As Simen said, we already have extern (C++). But I can absolutely change 
this if people wants to.


 Regarding this syntax:

 void insertItem(ObjcObject object, NSInteger value)
 [insertItemWithObjectValue:atIndex:];

 Is it possible and good to replace it with some UDA?


We could use an attribute. But I don't think it would be possible to use 
an UDA. Currently the compiler doesn't know anything about a particular 
UDA, all UDA's are treated the same. It it's either a built in attribute 
or an UDA. Doing something in between would be a lot harder.


 It seems contain some different things/syntax. I don't know how much
 Walter&Co will appreciate it.


I would say that it's very little new syntax, surprisingly. But 
semantically there's a lot of new stuff. But the core things are just 
the same as with extern (C), making D ABI compatible with another 
language, Objective-C. I think that this is mostly is a non-breaking 
change. All new keywords are prefix with two underscores, which is 
reserved by the compiler. A lot of stuff only apply for classes/methods 
declared as extern (Objective-C).

* extern (Objective-C) - I wouldn't really consider this new syntax

* [foo:bar:] - New syntax. Does not have to use this exact syntax but 
the functionality it provides is essential.

* Constructors in interfaces - Not really a new syntax. Just allows an 
existing syntax to be used in a new place.

* Foo.class - I guess this technically is new syntax. The only thing 
making this new syntax is the use of keyword. I we really don't want 
this we could rename it to __class or similar.

* __classext - Not implement yet, so that's up for discussion

* String literals - No new syntax. Just an implicit conversion added

* BOOL __selector(NSString) - New syntax. Kind of essential to have.

* Foo.protocolof - Not really a new syntax either. I don't think this is 
as essential as the other features.

*  IBOutlet and  IBAction - Not implemented. This could possibly be 
implemented as dummy UDA's.

* Blocks - Not implemented. I'm wondering if we could use the delegate 
keyword for this. If a delegate is marked as extern (Objective-C) it's a 
block. Or that might perhaps be confusing.

-- 
/Jacob Carlborg
Jun 24 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-24 10:04:01 +0000, Jacob Carlborg <doob me.com> said:


 Regarding this syntax:
 
 void insertItem(ObjcObject object, NSInteger value)
 [insertItemWithObjectValue:atIndex:];
 
 Is it possible and good to replace it with some UDA?


 
 We could use an attribute. But I don't think it would be possible to 
 use an UDA. Currently the compiler doesn't know anything about a 
 particular UDA, all UDA's are treated the same. It it's either a built 
 in attribute or an UDA. Doing something in between would be a lot 
 harder.


Not necessarily. There's a couple of Objective-C classes that get 
special treatment by the compiler (identified by a pragma). One could 
do the same for an UDA so the compiler would know where to get that 
value. I'd surely have implemented it as an UDA if such a thing existed 
at the time.

Perhaps we should use a string UDA. ;-) (joke)


 It seems contain some different things/syntax. I don't know how much
 Walter&Co will appreciate it.


 
 I would say that it's very little new syntax, surprisingly. But 
 semantically there's a lot of new stuff. But the core things are just 
 the same as with extern (C), making D ABI compatible with another 
 language, Objective-C. I think that this is mostly is a non-breaking 
 change.


It indeed is an additive and non-breaking change.


 All new keywords are prefix with two underscores, which is reserved by 
 the compiler. A lot of stuff only apply for classes/methods declared as 
 extern (Objective-C).
 
 * extern (Objective-C) - I wouldn't really consider this new syntax
 
 * [foo:bar:] - New syntax. Does not have to use this exact syntax but 
 the functionality it provides is essential.
 
 * Constructors in interfaces - Not really a new syntax. Just allows an 
 existing syntax to be used in a new place.


And it's only allowed in extern (Objective-C) interfaces because it 
does not make much sense for D interfaces.


 * Foo.class - I guess this technically is new syntax. The only thing 
 making this new syntax is the use of keyword. I we really don't want 
 this we could rename it to __class or similar.


It is a new syntax. This "function" needs special semantic treatment by 
the compiler because it returns an object of a different class 
depending on the type or object you're calling it on. It also mirrors 
the method named "class" in Objective-C. Given these data points, it 
seemed appropriate to use the class keyword, which hints at the 
compiler magic. Hence why I tweaked the syntax to allow ".class" on 
Objective-C classes and objects.


 * __classext - Not implement yet, so that's up for discussion
 
 * String literals - No new syntax. Just an implicit conversion added


I'm particularly proud of those string literals. They're way cleaner 
than their Objective-C counterparts.  :-)


 * BOOL __selector(NSString) - New syntax. Kind of essential to have.


Those too are better than their Objective-C counterpart too as they 
carry the argument and return type, making them less error-prone.


 * Foo.protocolof - Not really a new syntax either. I don't think this 
 is as essential as the other features.


It gives you the pointer for protocol (interface) Foo. You need that if 
you want to check at runtime if a class conforms to this protocol (or 
implements this interface in D parlance).


 *  IBOutlet and  IBAction - Not implemented. This could possibly be 
 implemented as dummy UDA's.
 
 * Blocks - Not implemented. I'm wondering if we could use the delegate 
 keyword for this. If a delegate is marked as extern (Objective-C) it's 
 a block. Or that might perhaps be confusing.


Blocks are reference-counted and don't share the two-pointer layout of 
a delegate. I'm not sure it'd be wise to call them delegates. But this 
needs some more thinking.

Finally, there is a couple of features that were added to Objective-C 
since then that should be added to the todo list to keep feature 
parity. Some of those, if implemented right, could benefit the rest of 
D too. For instance: ARC (automatic reference counting) which is 
becoming a must in Objective-C.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca/
Jun 24 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 6:27 AM, Michel Fortin wrote:

 Finally, there is a couple of features that were added to Objective-C since
then
 that should be added to the todo list to keep feature parity. Some of those, if
 implemented right, could benefit the rest of D too. For instance: ARC
(automatic
 reference counting) which is becoming a must in Objective-C.


Arc has very serious problems - I don't see how it can be done and be memory 
safe without adding extensive pointer annotations. The general problem is 
someone taking the address of a member of the reference counted object. The rc 
goes to zero, the objects gets deleted, and there's that dangling pointer to it.
Jun 24 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 24 June 2013 at 17:53:36 UTC, Walter Bright wrote:

 Arc has very serious problems - I don't see how it can be done 
 and be memory safe without adding extensive pointer 
 annotations. The general problem is someone taking the address 
 of a member of the reference counted object. The rc goes to 
 zero, the objects gets deleted, and there's that dangling 
 pointer to it.


Just thinking out loud, but what if we were able to  disable the 
& operator? Then if you needed its address, we could do it with 
some other member function that returns a special type that does 
the refcount. That'd be a fairly minor language change and would 
seal the gap that the library could then fill back in.
Jun 24 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 13:53:40 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 6/24/2013 6:27 AM, Michel Fortin wrote:

 Finally, there is a couple of features that were added to Objective-C  
 since then
 that should be added to the todo list to keep feature parity. Some of  
 those, if
 implemented right, could benefit the rest of D too. For instance: ARC  
 (automatic
 reference counting) which is becoming a must in Objective-C.


 Arc has very serious problems - I don't see how it can be done and be  
 memory safe without adding extensive pointer annotations. The general  
 problem is someone taking the address of a member of the reference  
 counted object. The rc goes to zero, the objects gets deleted, and  
 there's that dangling pointer to it.


All data members in Objective-C are private.  So the object can control  
when it gives out this data, and take appropriate actions.  AFAIK, ARC  
does not worry about internal pointers.

-Steve
Jun 24 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 11:03 AM, Steven Schveighoffer wrote:

 All data members in Objective-C are private.  So the object can control when it
 gives out this data, and take appropriate actions.  AFAIK, ARC does not worry
 about internal pointers.


Hmm, that's a good thought. (But recall that modules allow access to private 
members.)
Jun 24 2013
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 14:25:40 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 6/24/2013 11:03 AM, Steven Schveighoffer wrote:

 All data members in Objective-C are private.  So the object can control  
 when it
 gives out this data, and take appropriate actions.  AFAIK, ARC does not  
 worry
 about internal pointers.


 Hmm, that's a good thought. (But recall that modules allow access to  
 private members.)


hehe, no I mean in Objective-C, instance variables are ALWAYS private.   
Unless you leak that address out to the world, nobody will be getting it.

Typically, you don't give out addresses to anything but Objective-C object  
members, which are themselves reference counted.  All member variables  
that are 'public' are accessed via properties.

If you do give out addresses to member variables, you have to be wary of  
this problem.

-Steve
Jun 24 2013
prev sibling parent reply "Suliman" <evermind live.ru> writes:
Could anybody explain the practical side of this project? Where 
it can be helpful?
Jun 24 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 16:36:50 -0400, Suliman <evermind live.ru> wrote:


 Could anybody explain the practical side of this project? Where it can  
 be helpful?


First, you should quote the bit of the post that you are responding to.   
Since you responded to my post, I will answer.

Objective C is the main development language used on apple systems (iOS,  
MacOS X, etc).  Currently, D supports MacOS X.  So accessing Apple's OS  
framework (including GUI and other OS frameworks)from D requires either  
building a bridge between the two sides (basically, writing a C "glue  
layer" since both natively support C), or binding directly to Objective C.

Given that Objective C is a superset of C, and D supports C natively, just  
like Objective C, the benefit is huge.  Instead of calling some glue code,  
I can call Objective C objects directly.  Unlike most languages, there  
would not need to be ANY significant glue code here, just a mapping of  
what to call when you are on an Objective C object.  There should be  
almost no performance hit.

-Steve
Jun 24 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:45 PM, Steven Schveighoffer wrote:

 On Mon, 24 Jun 2013 16:36:50 -0400, Suliman <evermind live.ru> wrote:


 Could anybody explain the practical side of this project? Where it can be
 helpful?


 First, you should quote the bit of the post that you are responding to.  Since
 you responded to my post, I will answer.

 Objective C is the main development language used on apple systems (iOS, MacOS
 X, etc).  Currently, D supports MacOS X.  So accessing Apple's OS framework
 (including GUI and other OS frameworks)from D requires either building a bridge
 between the two sides (basically, writing a C "glue layer" since both natively
 support C), or binding directly to Objective C.

 Given that Objective C is a superset of C, and D supports C natively, just like
 Objective C, the benefit is huge.  Instead of calling some glue code, I can
call
 Objective C objects directly.  Unlike most languages, there would not need to
be
 ANY significant glue code here, just a mapping of what to call when you are on
 an Objective C object.  There should be almost no performance hit.


Yup. A big win for Mac developers.
Jun 24 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-24 17:53:40 +0000, Walter Bright <newshound2 digitalmars.com> said:


 On 6/24/2013 6:27 AM, Michel Fortin wrote:

 Finally, there is a couple of features that were added to Objective-C 
 since then
 that should be added to the todo list to keep feature parity. Some of those, if
 implemented right, could benefit the rest of D too. For instance: ARC 
 (automatic
 reference counting) which is becoming a must in Objective-C.


 
 Arc has very serious problems - I don't see how it can be done and be 
 memory safe without adding extensive pointer annotations. The general 
 problem is someone taking the address of a member of the reference 
 counted object. The rc goes to zero, the objects gets deleted, and 
 there's that dangling pointer to it.


That's not a so big problem: just disallow taking pointers to member 
variables inside of reference-counted memory blocks. At least in SafeD. 
This is a quite rare thing to do in Objective-C anyway, I'd be 
surprised if it bothered anyone.

And I don't think it is very common in D either. Either way, if D was 
to implement ARC for its own memory allocator instead of the current GC 
(which would be great) there's noting to prevent implementing it so 
that reference counts could be incremented from the middle address of a 
memory block, it'd be quite easy in fact, and quite necessary too 
because of the way arrays work.

Usually, the most annoying part of ARC is retain cycles, especially 
implicit ones created by blocks (Objective-C's delegate literals).

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca/
Jun 24 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:18 PM, Michel Fortin wrote:

 That's not a so big problem: just disallow taking pointers to member variables
 inside of reference-counted memory blocks. At least in SafeD. This is a quite
 rare thing to do in Objective-C anyway, I'd be surprised if it bothered anyone.

 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC (which
 would be great) there's noting to prevent implementing it so that reference
 counts could be incremented from the middle address of a memory block, it'd be
 quite easy in fact, and quite necessary too because of the way arrays work.

 Usually, the most annoying part of ARC is retain cycles, especially implicit
 ones created by blocks (Objective-C's delegate literals).


If the ref-counted blocks are allocated in the GC space, a GC run will get rid 
of them!
Jun 24 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:18 PM, Michel Fortin wrote:

 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC (which
 would be great) there's noting to prevent implementing it so that reference
 counts could be incremented from the middle address of a memory block, it'd be
 quite easy in fact, and quite necessary too because of the way arrays work.


 From my reading about ARC, it seems to me that we should support it now rather 
than later because:

1. people will expect it of D

2. non-ARC is inherently unsafe

3. migrating non-ARC code to ARC is error-prone and a major nuisance

4. non-O-C programs can also benefit from ARC (after all, reliance on the GC is 
the perennial dealbreaker for people wanting to migrate high performance code
to D)
Jun 25 2013
next sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-25 18:06:33 +0000, Walter Bright <newshound2 digitalmars.com> said:


 On 6/24/2013 1:18 PM, Michel Fortin wrote:

 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC (which
 would be great) there's noting to prevent implementing it so that reference
 counts could be incremented from the middle address of a memory block, it'd be
 quite easy in fact, and quite necessary too because of the way arrays work.


 
 From my reading about ARC, it seems to me that we should support it now 
 rather than later because:
 
 1. people will expect it of D
 
 2. non-ARC is inherently unsafe
 
 3. migrating non-ARC code to ARC is error-prone and a major nuisance
 
 4. non-O-C programs can also benefit from ARC (after all, reliance on 
 the GC is the perennial dealbreaker for people wanting to migrate high 
 performance code to D)


Exactly. Even without support for Objective-C, ARC in D is a very 
desirable feature. Beside that, the C++/COM WinRT API also uses ARC 
now, so I'd say it's becoming a must have pretty quickly.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca/
Jun 25 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-25 20:06, Walter Bright wrote:


 3. migrating non-ARC code to ARC is error-prone and a major nuisance


Xcode provides refactoring tools to migrate manual reference counting 
and GC code to ARC.


 4. non-O-C programs can also benefit from ARC (after all, reliance on
 the GC is the perennial dealbreaker for people wanting to migrate high
 performance code to D)


Absolutely.

-- 
/Jacob Carlborg
Jun 25 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 1:08 PM, Jacob Carlborg wrote:

 On 2013-06-25 20:06, Walter Bright wrote:


 3. migrating non-ARC code to ARC is error-prone and a major nuisance


 Xcode provides refactoring tools to migrate manual reference counting and GC
 code to ARC.


Those don't work with D.

Let's do it right the first time, and we won't have migration issues.
Jun 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 22:18, Walter Bright wrote:


 Those don't work with D.

 Let's do it right the first time, and we won't have migration issues.


Right, forgot to add: "for Objective-C".

-- 
/Jacob Carlborg
Jun 25 2013
prev sibling parent Manu <turkeyman gmail.com> writes:
On 26 June 2013 04:06, Walter Bright <newshound2 digitalmars.com> wrote:


 On 6/24/2013 1:18 PM, Michel Fortin wrote:


 And I don't think it is very common in D either. Either way, if D was to
 implement ARC for its own memory allocator instead of the current GC
 (which
 would be great) there's noting to prevent implementing it so that
 reference
 counts could be incremented from the middle address of a memory block,
 it'd be
 quite easy in fact, and quite necessary too because of the way arrays
 work.


 From my reading about ARC, it seems to me that we should support it now
 rather than later because:

 1. people will expect it of D

 2. non-ARC is inherently unsafe

 3. migrating non-ARC code to ARC is error-prone and a major nuisance

 4. non-O-C programs can also benefit from ARC (after all, reliance on the
 GC is the perennial dealbreaker for people wanting to migrate high
 performance code to D)


Yay! Since the conference, I'm finding myself more and more convinced that
what I actually want is ARC rather than GC... although this is just a
feeling, and completely untested in practise ;)
But I have experience with ARC on other platforms, and the fact it results
in predictable patterns makes it much easier to work with it.
Jun 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-24 15:27, Michel Fortin wrote:


 Not necessarily. There's a couple of Objective-C classes that get
 special treatment by the compiler (identified by a pragma). One could do
 the same for an UDA so the compiler would know where to get that value.
 I'd surely have implemented it as an UDA if such a thing existed at the
 time.


The thing is that pragmas are tied to the compiler. It knows the 
difference between pragma(foo) and pragma(bar). But for UDA's they are 
all treated the same, there's no difference between  (3),  ("asd") and 
 foo from the compiler's point of view (as far as I understand). You 
could implement it as a new attribute (that is, not an UDA), but to 
implement it as an UDA would be a totally new thing.


 I'm particularly proud of those string literals. They're way cleaner
 than their Objective-C counterparts.  :-)


I agree.


 Those too are better than their Objective-C counterpart too as they
 carry the argument and return type, making them less error-prone.


Same thing here.


 Blocks are reference-counted and don't share the two-pointer layout of a
 delegate. I'm not sure it'd be wise to call them delegates. But this
 needs some more thinking.


Right, they seem kind of complicated in regards of the struct layout 
it's implemented as. Seems to vary quite much depending on how the block 
is used and how outer variables are referenced.


 Finally, there is a couple of features that were added to Objective-C
 since then that should be added to the todo list to keep feature parity.
 Some of those, if implemented right, could benefit the rest of D too.
 For instance: ARC (automatic reference counting) which is becoming a
 must in Objective-C.


Yes. There are a couple of new features that D can take advantage of 
without adding new language support. I'm thinking of the simplified 
operator overloading that was added, last year I think. We already have 
operator overloading and can add that to the bindings, no need for 
language support.

If we want to add support for the new literals (numbers, arrays and 
associative arrays) we could do the same thing as we already done for 
strings.

And last, modules that was added this year, D has had that for years :)

-- 
/Jacob Carlborg
Jun 24 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 24 Jun 2013 22:30:56 +0200
schrieb Jacob Carlborg <doob me.com>:


 On 2013-06-24 15:27, Michel Fortin wrote:
 

 Not necessarily. There's a couple of Objective-C classes that get
 special treatment by the compiler (identified by a pragma). One
 could do the same for an UDA so the compiler would know where to
 get that value. I'd surely have implemented it as an UDA if such a
 thing existed at the time.


 
 The thing is that pragmas are tied to the compiler. It knows the 
 difference between pragma(foo) and pragma(bar). But for UDA's they
 are all treated the same, there's no difference between  (3),
  ("asd") and  foo from the compiler's point of view (as far as I
 understand). You could implement it as a new attribute (that is, not
 an UDA), but to implement it as an UDA would be a totally new thing.


Maybe it's new in dmd but gdc already has an UDA which is recognized by
the compiler:
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
https://github.com/D-Programming-GDC/GDC/commit/afb27a0048cbf51d40abc2810b85641d9e9af9dc

The benefit of an UDA is that it does not pollute the global namespace
like a normal attribute would.
Jun 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 08:53, Johannes Pfau wrote:


 Maybe it's new in dmd but gdc already has an UDA which is recognized by
 the compiler:
 https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d
 https://github.com/D-Programming-GDC/GDC/commit/afb27a0048cbf51d40abc2810b85641d9e9af9dc

 The benefit of an UDA is that it does not pollute the global namespace
 like a normal attribute would.


Ok, I see. I don't know if that is implemented in DMD, not that I've 
heard of. But implementing this in DMD would be more work and would be 
yet another new feature. Note, I'm not saying I'm against it, I just 
want to limit how many new features are added to increase the chance of 
this getting into main line.

-- 
/Jacob Carlborg
Jun 25 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 3:04 AM, Jacob Carlborg wrote:

 On 2013-06-23 23:02, bearophile wrote:


 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)


 As Simen said, we already have extern (C++). But I can absolutely change this
if
 people wants to.


Objective-C is just perfect.
Jun 24 2013
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 24 June 2013 at 17:51:08 UTC, Walter Bright wrote:

 On 6/24/2013 3:04 AM, Jacob Carlborg wrote:

 On 2013-06-23 23:02, bearophile wrote:


 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)


 As Simen said, we already have extern (C++). But I can 
 absolutely change this if
 people wants to.


 Objective-C is just perfect.


linkageAttribute:
       'extern' '(' Identifier ')'
     | 'extern' '(' Identifier '++' ')'
     | 'extern' '(' Identifier '-' Identifier ')'
     ;
Jun 24 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 24.06.2013 20:10, schrieb Brian Schott:

 On Monday, 24 June 2013 at 17:51:08 UTC, Walter Bright wrote:

 On 6/24/2013 3:04 AM, Jacob Carlborg wrote:

 On 2013-06-23 23:02, bearophile wrote:


 Instead of:
 extern (Objective-C)

 Is it better to use a naming more D-idiomatic?

 extern (Objective_C)


 As Simen said, we already have extern (C++). But I can absolutely
 change this if
 people wants to.


 Objective-C is just perfect.


 
 linkageAttribute:
       'extern' '(' Identifier ')'
     | 'extern' '(' Identifier '++' ')'
     | 'extern' '(' Identifier '-' Identifier ')'
     ;


Maybe it makes sense to generalize it instead:

linkageAttribute: 'extern' '(' linkageAttributeIdentifier ')';

linkageAttributeIdentifier:
        linkageAttributeToken
      | linkageAttributeIdentifier linkageAttributeToken
      ;
Jun 26 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/23/2013 1:24 PM, Jacob Carlborg wrote:

 As some of you might know Michel Fortin created a fork of DMD a couple of years
 ago which add support for using Objective-C classes and calling Objective-C
 method. That is making D ABI compatible with Objective-C.

 I have now updated it to the latest version of DMD and druntime. All
 D/Objective-C tests pass and all standard tests pass. I'm planning to create a
 DIP for this and would really like this to be folded into main line. For know
 you can read the design document created by Michel:


Thank you for reviving this. Please carry on!
Jun 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-23 23:12, Walter Bright wrote:


 Thank you for reviving this. Please carry on!


Is there a chance we can get this into main line?

-- 
/Jacob Carlborg
Jun 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 3:04 AM, Jacob Carlborg wrote:

 On 2013-06-23 23:12, Walter Bright wrote:


 Thank you for reviving this. Please carry on!


 Is there a chance we can get this into main line?


Yes, but since I don't know much about O-C programming, the feature should be 
labeled "experimental" until we're sure it's the right design.
Jun 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-24 19:36, Walter Bright wrote:


 Yes, but since I don't know much about O-C programming, the feature
 should be labeled "experimental" until we're sure it's the right design.


Absolutely. But there's not that much to design. It's the same with 
extern (C) nothing to design there, just get the ABI correct. Compared 
to extern (C) there are a few additional things that need to be designed.

I suggest you try and read the design document by Michel, then comment 
and ask as much questions as possible.

-- 
/Jacob Carlborg
Jun 24 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2013 1:37 PM, Jacob Carlborg wrote:

 On 2013-06-24 19:36, Walter Bright wrote:


 Yes, but since I don't know much about O-C programming, the feature
 should be labeled "experimental" until we're sure it's the right design.


 Absolutely. But there's not that much to design. It's the same with extern (C)
 nothing to design there, just get the ABI correct. Compared to extern (C) there
 are a few additional things that need to be designed.


The difference is I know C intimately.



 I suggest you try and read the design document by Michel, then comment and ask
 as much questions as possible.


I did read it.
Jun 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-24 22:49, Walter Bright wrote:


 The difference is I know C intimately.


Fair enough. Please ask any questions and we will try and answer.


 I did read it.


Great.

-- 
/Jacob Carlborg
Jun 24 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 Yes, but since I don't know much about O-C programming, the 
 feature should be labeled "experimental" until we're sure it's 
 the right design.


This change opens a new target of D development (well, it was 
already open for the people willing to use a not standard dmd 
compiler), but it also introduce some extra complexity in the 
language, that every D programmer will have to pay forever, even 
all the ones that will not use those features. So such changes 
need to be introduced with care and after extensive discussions 
in the main newsgroup. Probably each one new thing introduced 
needs a separate discussion.

Bye,
bearophile
Jun 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-24 23:26, bearophile wrote:


 This change opens a new target of D development (well, it was already
 open for the people willing to use a not standard dmd compiler), but it
 also introduce some extra complexity in the language, that every D
 programmer will have to pay forever, even all the ones that will not use
 those features. So such changes need to be introduced with care and
 after extensive discussions in the main newsgroup. Probably each one new
 thing introduced needs a separate discussion.


I don't think it adds much complexity. If you don't use extern 
(Objective-C) you don't need to learn it.

-- 
/Jacob Carlborg
Jun 24 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 I don't think it adds much complexity. If you don't use extern 
 (Objective-C) you don't need to learn it.


D books must be bigger, D programmers must read those parts of 
the books, the error messages become more complex (because you 
can hit by mistake the unwanted syntax, or because the compiler 
recovering of errors must consider more possibilities), the 
compiler gets a little larger. Thinking that some new syntax has 
no costs is very wrong.

Bye,
bearophile
Jun 24 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jun 2013 18:10:19 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Jacob Carlborg:


 I don't think it adds much complexity. If you don't use extern  
 (Objective-C) you don't need to learn it.


 D books must be bigger, D programmers must read those parts of the  
 books, the error messages become more complex (because you can hit by  
 mistake the unwanted syntax, or because the compiler recovering of  
 errors must consider more possibilities), the compiler gets a little  
 larger. Thinking that some new syntax has no costs is very wrong.


I think this is largely false.  In order for the new syntax to be valid,  
you must use extern(Objective-C).  That would be quite an accident.

Consider that I have never dealt with the COM compatibility (or frankly,  
even the extern(C++) compatibility) part of D whatsoever.  Because I've  
never implemented IUnknown, or used extern(C++).

These features that are enabled by specific syntax are not extra  
complexity for D.

Note that TDPL makes no mention of IUnknown or COM compatibility, yet I  
have never seen a post on D.learn asking questions about this feature set  
unless they were actually looking to write COM code.  In other words, no  
accidental enabling (I have seen questions as to why interfaces are not  
Objects, and I grudgingly have to point to the incorrect belief that COM  
objects cannot be discerned from normal D objects at compile time).

On the other hand, something like shared and const are pervasive, because  
they are core language features, AND because they are used throughout  
libraries.

I think it is important to consider the applicability to normal code when  
introducing such binding features.  The way this is to be introduced is  
the correct level of access -- only enabled with a specific directive.

-Steve
Jun 24 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-25 00:39, Steven Schveighoffer wrote:


 I think this is largely false.  In order for the new syntax to be valid,
 you must use extern(Objective-C).  That would be quite an accident.

 Consider that I have never dealt with the COM compatibility (or frankly,
 even the extern(C++) compatibility) part of D whatsoever.  Because I've
 never implemented IUnknown, or used extern(C++).


I agree, I never used those either.


 These features that are enabled by specific syntax are not extra
 complexity for D.

 Note that TDPL makes no mention of IUnknown or COM compatibility, yet I
 have never seen a post on D.learn asking questions about this feature
 set unless they were actually looking to write COM code.  In other
 words, no accidental enabling (I have seen questions as to why
 interfaces are not Objects, and I grudgingly have to point to the
 incorrect belief that COM objects cannot be discerned from normal D
 objects at compile time).

 On the other hand, something like shared and const are pervasive,
 because they are core language features, AND because they are used
 throughout libraries.

 I think it is important to consider the applicability to normal code
 when introducing such binding features.  The way this is to be
 introduced is the correct level of access -- only enabled with a
 specific directive.


Well put, you said it better than I ever could.

-- 
/Jacob Carlborg
Jun 25 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 24 June 2013 at 22:39:13 UTC, Steven Schveighoffer 
wrote:

 On Mon, 24 Jun 2013 18:10:19 -0400, bearophile 
 <bearophileHUGS lycos.com> wrote:


 Jacob Carlborg:


 I don't think it adds much complexity. If you don't use 
 extern (Objective-C) you don't need to learn it.


 D books must be bigger, D programmers must read those parts of 
 the books, the error messages become more complex (because you 
 can hit by mistake the unwanted syntax, or because the 
 compiler recovering of errors must consider more 
 possibilities), the compiler gets a little larger. Thinking 
 that some new syntax has no costs is very wrong.


 I think this is largely false.  In order for the new syntax to 
 be valid, you must use extern(Objective-C).  That would be 
 quite an accident.

 Consider that I have never dealt with the COM compatibility (or 
 frankly, even the extern(C++) compatibility) part of D 
 whatsoever.  Because I've never implemented IUnknown, or used 
 extern(C++).

 These features that are enabled by specific syntax are not 
 extra complexity for D.

 Note that TDPL makes no mention of IUnknown or COM 
 compatibility, yet I have never seen a post on D.learn asking 
 questions about this feature set unless they were actually 
 looking to write COM code.  In other words, no accidental 
 enabling (I have seen questions as to why interfaces are not 
 Objects, and I grudgingly have to point to the incorrect belief 
 that COM objects cannot be discerned from normal D objects at 
 compile time).


This will surely change if we ever want to target WinRT with D, 
as it is COM based and might be the future Windows default API in 
the long term.

I am quite curious to see the presentations of this week BUILD 
2012, to see what changes Microsoft might be briging to WinRT.

--
Paulo
Jun 25 2013
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 24.06.2013 23:26, schrieb bearophile:

 Walter Bright:
 

 Yes, but since I don't know much about O-C programming, the feature
 should be labeled "experimental" until we're sure it's the right design.


 
 This change opens a new target of D development (well, it was already
 open for the people willing to use a not standard dmd compiler), but it
 also introduce some extra complexity in the language, that every D
 programmer will have to pay forever, even all the ones that will not use
 those features. So such changes need to be introduced with care and
 after extensive discussions in the main newsgroup. Probably each one new
 thing introduced needs a separate discussion.
 
 Bye,
 bearophile


I agree. Even though it may not be mentioned in books and many people
may never see the changes, it still *does* make the language more
complex. One consequence is that language processing tools (compilers,
syntax highlighters etc.) get updated/written with this in mind.

This is why I would also suggest to try and make another pass over the
changes, trying to move every bit from language to library that is
possible - without compromising the result too much, of course (e.g. due
to template bloat like in the older D->ObjC bridge). Maybe it's possible
to put some things into __traits or other more general facilities to
avoid changing the language grammar.

On the other hand I actually very much hate to suggest this, as it
probably causes a lot of additional work. But really, we shouldn't take
*any* language additions lightly, even relatively isolated ones. Like
always, new syntax must be able to "pull its own weight" (IMO, of course).
Jun 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-26 10:54, Sönke Ludwig wrote:


 I agree. Even though it may not be mentioned in books and many people
 may never see the changes, it still *does* make the language more
 complex. One consequence is that language processing tools (compilers,
 syntax highlighters etc.) get updated/written with this in mind.


I don't think there will require much change for tools (non-compilers). 
I see three "big" changes, non of them are at the lexical level:

extern (Objective-C)
[foo:bar:]
foo.class

Any tool that just deals with syntax highlighting (on a lexical level) 
should be able to handle these changes. Sure, you might want to add a 
special case for "foo.class" to not highlight "class" in this case.


 This is why I would also suggest to try and make another pass over the
 changes, trying to move every bit from language to library that is
 possible - without compromising the result too much, of course (e.g. due
 to template bloat like in the older D->ObjC bridge). Maybe it's possible
 to put some things into __traits or other more general facilities to
 avoid changing the language grammar.


I don't see what could be but in __traits that could help. Do you have 
any suggestions?


 On the other hand I actually very much hate to suggest this, as it
 probably causes a lot of additional work. But really, we shouldn't take
 *any* language additions lightly, even relatively isolated ones. Like
 always, new syntax must be able to "pull its own weight" (IMO, of course).


I would say that for anyone remotely interested in Mac OS X or iOS 
development it pull its own weight several times over. In my opinion I 
think it's so obvious it pulls its own weight I shouldn't need to 
justify the changes.

-- 
/Jacob Carlborg
Jun 26 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 26.06.2013 12:09, schrieb Jacob Carlborg:

 On 2013-06-26 10:54, Sönke Ludwig wrote:
 

 I agree. Even though it may not be mentioned in books and many people
 may never see the changes, it still *does* make the language more
 complex. One consequence is that language processing tools (compilers,
 syntax highlighters etc.) get updated/written with this in mind.


 
 I don't think there will require much change for tools (non-compilers).
 I see three "big" changes, non of them are at the lexical level:


I agree, it will only influence tools that include a parser. Few syntax
highlighters parse the code (although *some* do), so this was probably
not the best example.


 This is why I would also suggest to try and make another pass over the
 changes, trying to move every bit from language to library that is
 possible - without compromising the result too much, of course (e.g. due
 to template bloat like in the older D->ObjC bridge). Maybe it's possible
 to put some things into __traits or other more general facilities to
 avoid changing the language grammar.


 
 I don't see what could be but in __traits that could help. Do you have
 any suggestions?


Naively I first thought that .class and .protocolof were candidates for
__traits, but actually it looks like they might simply be implemented
using a templated static property:

class ObjcObject {
  static  property ProtocolType!T protocolof(this T)() {
    return ProtocolType!T.staticInstance;
  }
}

That's of course assuming that the static instance is somehow accessible
from normal D code. Sorry if this doesn't really make sense, I don't
know anything of the implementation details.

The __selector type class might be replaceable by a library type
Selector!(R, ARGS). It would also be great to have general support for
implicit constructors and make string->NSString and delegate->ObjcBlock
available in the library instead of dedicated compiler special case.

Not sure about constructors in interfaces, they seem a bit odd, but
using "init" instead and letting "new" call that is also odd...

You already mentioned  IBAction and  IBOutlet, those can obviously be
UDAs, as well as  optional and other similar keywords.

Maybe it's possible like this to reduce the syntax additions to
extern(Objective-C) and possibly constructors in interfaces.


 

 On the other hand I actually very much hate to suggest this, as it
 probably causes a lot of additional work. But really, we shouldn't take
 *any* language additions lightly, even relatively isolated ones. Like
 always, new syntax must be able to "pull its own weight" (IMO, of
 course).


 
 I would say that for anyone remotely interested in Mac OS X or iOS
 development it pull its own weight several times over. In my opinion I
 think it's so obvious it pulls its own weight I shouldn't need to
 justify the changes.
 


I don't mean the additions as a whole of course, but each single
language change vs. a library based solution of the same feature ;) In
general this is a great addition from a functional view! I was very much
looking forward for it to get back to life.
Jun 26 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-06-26 13:07, Sönke Ludwig wrote:


 I agree, it will only influence tools that include a parser. Few syntax
 highlighters parse the code (although *some* do), so this was probably
 not the best example.


Absolutely, some even do semantic analyze. Example, the syntax 
highlighter in Eclipse for Java highlights instance variables 
differently from identifiers. Don't know if there's any syntax 
highlighters for D that do this.


 Naively I first thought that .class and .protocolof were candidates for
 __traits, but actually it looks like they might simply be implemented
 using a templated static property:

 class ObjcObject {
    static  property ProtocolType!T protocolof(this T)() {
      return ProtocolType!T.staticInstance;
    }
 }


So what would ProtocolType do? I think I need to look at the 
implementation of .class and .protocolof. In Objective-C there are 
runtime functions to do the same, I don't know if those would work for D 
as well.


 That's of course assuming that the static instance is somehow accessible
 from normal D code. Sorry if this doesn't really make sense, I don't
 know anything of the implementation details.

 The __selector type class might be replaceable by a library type
 Selector!(R, ARGS).


Hmm, that might be possible. We would need a trait to get the selector 
for a method, which we should have anyway. But this uses templates 
again. We don't want to move everything to library code then we would 
have the same problem as with the bridge.


 It would also be great to have general support for
 implicit constructors and make string->NSString and delegate->ObjcBlock
 available in the library instead of dedicated compiler special case.


Since strings and delegates are already implemented in the language, 
would it be possible to add implicit conversions for these types in the 
library?


 Not sure about constructors in interfaces, they seem a bit odd, but
 using "init" instead and letting "new" call that is also odd...


Using "alloc.init" would be more Objective-C like and using "new" would 
be more D like.


 You already mentioned  IBAction and  IBOutlet, those can obviously be
 UDAs, as well as  optional and other similar keywords.


The compiler will need to know about  optional. I don't think that the 
compiler will need to know about  IBAction and  IBOutlet, but if it 
does, there are a couple of advantages we could implement.  IBOutlet 
only make sense on instance variables.  IBAction only make sense on 
instance method with the following signature:

void foo (id sender) { }

Possibly any Objective-C type could be used as the argument type.


 Maybe it's possible like this to reduce the syntax additions to
 extern(Objective-C) and possibly constructors in interfaces.


I'm open to suggestions.


 I don't mean the additions as a whole of course, but each single
 language change vs. a library based solution of the same feature ;) In
 general this is a great addition from a functional view! I was very much
 looking forward for it to get back to life.


Great. It's just a question of what is possible to implement in library 
code.

-- 
/Jacob Carlborg
Jun 26 2013
prev sibling parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-26 11:07:45 +0000, Sönke Ludwig <sludwig outerproduct.org> said:


 Naively I first thought that .class and .protocolof were candidates for
 __traits, but actually it looks like they might simply be implemented
 using a templated static property:
 
 class ObjcObject {
   static  property ProtocolType!T protocolof(this T)() {
     return ProtocolType!T.staticInstance;
   }
 }
 
 That's of course assuming that the static instance is somehow accessible
 from normal D code.


I don't think you get what protocolof is, or if so I can't understand 
what you're trying to suggest with the code above. It's a way to obtain 
the pointer identifying a protocol. You don't "call" protocolof on a 
class, but on the interface. Like this:

	extern (Objective-C) interface MyInterface {}

	NSObject object;
	if (object.conformsToProtocol(MyInterface.protocolof))
	{ … }

protocolof is a pointer generated by the compiler that represents the 
Objective-C protocol for that interface. It's pretty much alike other 
compiler generated properties such as mangleof and nameof. There's 
nothing unusual about protocolof.

And that conformsToProtocol function above is a completely normal 
function by the way.

As for .class, it's pretty much alike to .classinfo for D objects. The 
difference is that it returns an instance of a different type depending 
on the class (Objective-C has a metaclass hierarchy), so it needs to be 
handled by the compiler. I used .class to mirror the name in 
Objective-C code. Since this has to be compiler generated and it's type 
is magic to be typeof(this).Class, I see no harm in using a keyword for 
it. I could have called it .classinfo, but that'd be rather misleading 
if you asked me (it's not a ClassInfo object, nor does it behave like 
ClassInfo).


 The __selector type class might be replaceable by a library type
 Selector!(R, ARGS).


It could. But it needs compiler support for if you want to extract them 
from functions in a type-safe manner. If the compiler has to understand 
the type, better make it a language extension.


 It would also be great to have general support for
 implicit constructors and make string->NSString and delegate->ObjcBlock
 available in the library instead of dedicated compiler special case.


String literals are implicitly convertible to NSString with absolutely 
no overhead.


 Not sure about constructors in interfaces, they seem a bit odd, but
 using "init" instead and letting "new" call that is also odd...


Well, there's supported in Objective-C (as init methods), so we have to 
support them.


 You already mentioned  IBAction and  IBOutlet, those can obviously be
 UDAs, as well as  optional and other similar keywords.


Indeed.


 Maybe it's possible like this to reduce the syntax additions to
 extern(Objective-C) and possibly constructors in interfaces.


Maybe. But not at the cost of memory safety.

The idea is that something written in  safe D should be memory-safe, it 
should be provable by the compiler. And this should apply to 
Objective-C code written in D too. Without this requirement we could 
make it less magic, and allow, for instance, NSObject.alloc().init(). 
But that's not  safe, which is why constructors were implemented.

But we can't do this at the cost of disallowing existing idioms do in 
Objective-C. For instance, I could get a pointer to a class object, and 
create a new object for it. If you define this:

	extern (Objective-C):
	interface MyProtocol {
		this(string);
	}
	class MyObject : NSObject, MyProtocol {
		this(string) {}
	}

you can then write this:

	MyProtocol.Class c = MyObject.class;
	NSObject o = new c("baca");

And the compiler then knows that the class pointer can allocate objects 
that can be constructed with a string parameter. This is something that 
can and is done in Objective-C (hence why you'll find constructors on 
interfaces). The idea is to add provable memory safety on top of it. 
(Note that the above example is not implemented yet, nor documented.)

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca/
Jun 26 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-06-23 20:24:41 +0000, Jacob Carlborg <doob me.com> said:


 As some of you might know Michel Fortin created a fork of DMD a couple 
 of years ago which add support for using Objective-C classes and 
 calling Objective-C method. That is making D ABI compatible with 
 Objective-C.
 
 I have now updated it to the latest version of DMD and druntime. All 
 D/Objective-C tests pass and all standard tests pass.


I know it was significant work to make it both play nice with the most 
recent OS X linker and port it to the newest DMD code base. Great 
achievement.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca/
Jun 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-06-24 14:49, Michel Fortin wrote:


 I know it was significant work to make it both play nice with the most
 recent OS X linker and port it to the newest DMD code base. Great
 achievement.


Thank you for all the help I've got and for you starting with this whole 
project.

-- 
/Jacob Carlborg
Jun 24 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-23 22:24, Jacob Carlborg wrote:

 As some of you might know Michel Fortin created a fork of DMD a couple
 of years ago which add support for using Objective-C classes and calling
 Objective-C method. That is making D ABI compatible with Objective-C.

 I have now updated it to the latest version of DMD and druntime. All
 D/Objective-C tests pass and all standard tests pass. I'm planning to
 create a DIP for this and would really like this to be folded into main
 line. For know you can read the design document created by Michel:


I have created a proper DIP for this now. The DIP is basically Michel 
Fortin's original designed document properly formatted and put next to 
the other DIP's.

DIP link: http://wiki.dlang.org/DIP43
Thread for the DIP: 
http://forum.dlang.org/thread/kqmlm7$1kfi$1 digitalmars.com#post-kqmlm7:241kfi:241:40digitalmars.com

-- 
/Jacob Carlborg
Jun 29 2013
parent reply "Christian Schneider" <schneider gerzonic.net> writes:
I almost got Chocolate running on a 10.9.4 machine with all the
latest developer tools (including Xcode 6), all built from source
and 64 bit with the latest git checkouts (including phobos). Of
course it is not within Xcode but using dub, so the biggest thing
yet to do is to bundle an OSX app with dub, so far for the word
almost before ;)

This looks very promising, thank you Jacob for all the hard work!
I soon want to start to write a tutorial including a step by step
guide.
Sep 24 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-24 14:56, Christian Schneider wrote:

 I almost got Chocolate running on a 10.9.4 machine with all the
 latest developer tools (including Xcode 6), all built from source
 and 64 bit with the latest git checkouts (including phobos). Of
 course it is not within Xcode but using dub, so the biggest thing
 yet to do is to bundle an OSX app with dub, so far for the word
 almost before ;)

 This looks very promising, thank you Jacob for all the hard work!
 I soon want to start to write a tutorial including a step by step
 guide.


Cool, it's great to see that it's useful to someone.

-- 
/Jacob Carlborg
Sep 24 2014