<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">An error seems reasonable here.<div class=""><br class=""></div><div class=""><font face="Menlo" class="">Error: Ambiguous Objective-C case name for ‘.Two’.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">And then the Fix-It is just to put the second case on a new line and provide the <font face="Menlo" class="">@objc(<#name#>)</font> completion.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 1:56 AM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Does it make sense to put @objc(name) on enum cases? Such as<br class=""><br class="">@objc enum Foo: Int {<br class=""> @objc(kFooOne) case One<br class=""> @objc(kFooTwo) case Two<br class="">}<br class=""><br class="">The only real problem here is what do we do if you say<br class=""><br class="">@objc(kFooOne) case One, Two<br class=""><br class="">Either we just apply it to the One variant and ignore the Two variant, possibly with a warning, or we emit an error.<br class=""><br class="">-Kevin<br class=""><br class="">On Wed, Dec 9, 2015, at 06:01 PM, Jordan Rose wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Dec 9, 2015, at 15:18, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">Example:<br class=""><br class="">import Foundation<br class=""><br class="">class Foo: NSObject {<br class=""> @objc enum Bar: Int {<br class=""> case One, Two<br class=""> }<br class="">}<br class=""><br class="">This generates the following:<br class=""><br class="">SWIFT_CLASS("_TtC7unnamed3Foo")<br class="">@interface Foo : NSObject<br class="">- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;<br class="">@end<br class=""><br class="">typedef SWIFT_ENUM(NSInteger, Bar) {<br class=""> BarOne = 0,<br class=""> BarTwo = 1,<br class="">};<br class=""><br class="">I'd like to resolve this by saying @objc(FooBar) but that emits an error.<br class=""><br class="">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).<br class=""></blockquote><br class="">+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.<br class=""><br class="">Jordan<br class=""></blockquote>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>