<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 1:19 PM, 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="">I've now submitted this proposal as a PR: <a href="https://github.com/apple/swift-evolution/pull/50" class="">https://github.com/apple/swift-evolution/pull/50</a><br class=""></div></div></blockquote><div><br class=""></div><div>Thanks for writing this up!</div><div><br class=""></div><div>I was actually surprised that this didn’t already work; @objc is supposed to be able to rename effectively anything at this point. Given that, and that another core team member has already +1’d, we can skip the evolution process and call this a bug fix. Want to contribute a fix?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I listed one open question:<br class=""><br class="">Should the generated Obj-C declarations use the swift_name attribute to indicate the Swift type it came from? Proposal SE-0005 generalizes swift_name to apply to any arbitrary C or Obj-C entity, so it will be legal to put on enums.<br class=""><br class="">Labelling it makes it clear to the reader what the Swift equivalent is, but I'm unsure if there's any downsides to doing this.<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, it makes sense to use the swift_name attribute here. If you’re implementing your proposal, check out lib/PrintAsObjC/PrintAsObjC.cpp and how we use the SWIFT_COMPILE_NAME macro for this in the generated header.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-Kevin Ballard<br class=""><br class="">On Thu, Dec 10, 2015, at 09:45 PM, Chris Lattner wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Dec 9, 2015, at 3:18 PM, 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=""></blockquote><br class="">+1 to this idea.<br class=""><br class="">-Chris<br class=""><br class=""><br class=""><blockquote type="cite" 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=""><br class="">-Kevin Ballard<br class="">_______________________________________________<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=""></blockquote><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=""></body></html>