[swift-evolution] [discussion] Change the behavior of @objc on a class?

Jordan Rose jordan_rose at apple.com
Wed Jun 29 11:35:45 CDT 2016


> On Jun 28, 2016, at 21:50, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 
> 
> Regards
> LM
> (From mobile)
> 
> On Jun 28, 2016, at 8:04 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hey, all. An engineer at Apple noticed the following behavior:
>>> 
>>> 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) runtime name
>>> 2. @objc class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) runtime name
>>> 3. @objc(Foo) class Foo: NSObject → exposed to Objective-C, unmangled runtime name
>>> 
>>> (and 4. @objc class Foo → illegal, classes must have ObjC heritage to be @objc.)
>>> 
>>> They specifically observed that (1) and (2) have the same behavior, and suggested that maybe (2) should be shorthand for (3).
>>> 
>>> Pros:
>>> - There aren't two ways to spell (1).
>>> - Removing the mangling (and module uniquing) from the runtime name is probably one of the most common uses of @objc on a class.
>>> 
>>> Cons:
>>> - It's a source-breaking change, for all that the "@objc" in (2) is redundant.
>>> - For protocols, (1) and (2) are not equivalent, because @objc isn't inherited there.
>>> - Mangling is used to namespace class names at run time; if you drop that, the ObjC name should probably have a prefix. (This applies more to frameworks than apps, though.)
>> 
>> I’m -1 on this, because bare “@objc” in other contexts means “make sure this is exposed to Objective-C, but I don’t want to be explicit about the name” while “@objc(something)” means “make sure this is exposed to Objective-C, and ‘something’ is the name”. 
>> 
> 
> -1 
> Please'o'please ... I find it useful for complexifying simple swift names into the kind that typically exists on the objc side.

To be clear, the argument form wouldn’t change, but it seems like there’s enough negative feedback on this that we shouldn’t do it. Thanks, everyone!

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/d215a5a5/attachment.html>


More information about the swift-evolution mailing list