[natesm]

On one hand, it's nice, and it'll make coding in Obj-C nicer.

On the other hand, it strengthens the coupling between Objective-C the language the Cocoa the framework, and I'm not sure how I feel about that.

I do like it better than the property dot syntax though. (is a simple assignment to a struct member? is it an objc_msgSend of unknown complexity?)

[glhaynes]

Apple's weird in the way they couple things in different ways than the rest of the industry and against the conventional wisdom. Since essentially nobody has an investment in Objective-C-without-Cocoa or Cocoa-without-Objective-C, I don't see any problem with them evolving them together whichever way seems best to them.

Also, there's long precedent with @"…" syntax for embedding NSString literals and most of the changes are really just preprocessor/static analysis-driven syntactic sugar — sometimes extreme sugar, yes, but optional, highly-predictable, purely-syntactic-cleanup nonetheless. So if they ever decide "the future of Cocoa is Ruby!" or something like that, I'd think most of the sugar could be, to mix metaphors, transplanted.

On that note, though: I don't see Apple moving primarily away from Objective-C any sooner than I see .Net moving primarily away from C#. It's "the language" until something huge changes the landscape, in large part because they've been able to so substantially evolve it, just like Microsoft, who also controls the primary framework used with their language, has been able to do with C#.

[msbarnett]

This doesn't do much of anything to increase coupling to Cocoa.

It does represent yet another link between the language syntax and the Foundation framework (along with NSStrings, blocks, etc), but Foundation is effectively part of the language.

[ZenPsycho]

Are there any drawbacks/pitfalls involved in creating a compiler that translates these literals to some other data structure library (such as glib, for example)?