[swift-evolution] Proposal: Allow @objc(name) on enum declarations
Jordan Rose
jordan_rose at apple.com
Wed Dec 9 20:01:39 CST 2015
> On Dec 9, 2015, at 15:18, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>
> Swift allows for placing @objc on an enum that has an Int raw type in order to expose it to Obj-C. But it doesn't currently let you rename the enum when exposing it to Obj-C. This is particularly problematic when exposing a Swift enum that's nested in a struct/class, as the nesting resolves ambiguity in Swift but is not present in Obj-C.
>
> Example:
>
> import Foundation
>
> class Foo: NSObject {
> @objc enum Bar: Int {
> case One, Two
> }
> }
>
> This generates the following:
>
> SWIFT_CLASS("_TtC7unnamed3Foo")
> @interface Foo : NSObject
> - (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;
> @end
>
> typedef SWIFT_ENUM(NSInteger, Bar) {
> BarOne = 0,
> BarTwo = 1,
> };
>
> I'd like to resolve this by saying @objc(FooBar) but that emits an error.
>
> I'm also going to submit a separate proposal saying we should change the default naming here so the enum is named FooBar, but these two proposals go hand-in-hand (there are cases where you might want to rename a root-level enum, to add a prefix for disambiguation in Obj-C, or you may want to selectively opt out of the proposed renaming rules by forcing your nested enum to use just its name in Obj-C).
+1 to being able to rename @objc enums. I'm a little surprised we even allow exposing nested types to Objective-C, and am not at all sure the printer is set up to handle that correctly, but the renaming is independently useful.
Jordan
More information about the swift-evolution
mailing list