On 2013-06-24 10:04:01 +0000, Jacob Carlborg <doob@me.com> said: >> Regarding this syntax: >> >> void insertItem(ObjcObject object, NSInteger value) >> [insertItemWi thObjectValue: 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/