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

[Dave Abrahams]

on Mon Jun 27 2016, Jordan Rose <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.)
>
> There are probably people who say that last con applies to the
> generated header as well: we shouldn't put (1) or (2) into the
> generated header because the ObjC name might conflict with another
> class at compile time. This is valid, but probably too drastic a
> change at this point.
>
> So, what does everyone think? I'm leaning towards "no change" because
> it's a bit subtle and not a big enough win, but if there's widespread
> support for this I'll pull it into a proposal.

It seems like a win and the right solution.  Whether the win is “big
enough,” I can't say.

-- 
Dave