<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=""><div class="">My point is that Swift currently treats @objc on nested types differently based on whether the <i class="">outer</i> type is @objc—if the outer type is @objc, the inner types end up in the generated header; otherwise they don't. And what about @objc on local types?</div><div class=""><br class=""></div><div class="">(Right now we have a hole: an API using an @objc type will show up in the generated header, but the type may not, leading to errors in the header. We should resolve that somehow.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 21:36, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">We already default nested types to @nonobjc (hence the explicit @objc in my sample). I like that Swift supports using @objc on nested types, because that way I can avoid having to uglify my Swift API just for the sake of Obj-C compatibility (I know I can use a typealias inside the outer type to provide a convenient shorthand for the formerly-nested type, but I still consider that ugly).<br class=""><br class="">-Kevin<br class=""><br class="">On Wed, Dec 9, 2015, at 06:03 PM, Jordan Rose wrote:<br class=""><blockquote type="cite" class="">I would rather just not print nested types in the generated header. We already don't do so if the enclosing type is not Objective-C-compatible.<br class=""><br class="">Jordan<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 9, 2015, at 15:24, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">When exposing some type to Obj-C, if the type is nested within another type, the Obj-C name should include the enclosing types.<br class=""><br class="">For example:<br class=""><br class="">class Foo: NSObject {<br class=""> @objc enum Bar: Int {<br class=""> case One, Two<br class=""> }<br class=""> @objc class Baz: NSObject {}<br class="">}<br class=""><br class="">is currently exported to Swift as<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="">SWIFT_CLASS("_TtCC7unnamed3Foo3Baz")<br class="">@interface Baz : NSObject<br class="">- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;<br class="">@end<br class=""><br class="">I think it should be exported instead as<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, FooBar) {<br class=""> FooBarOne = 0,<br class=""> FooBarTwo = 1,<br class="">};<br class=""><br class="">SWIFT_CLASS("_TtCC7unnamed3Foo3Baz")<br class="">@interface FooBaz : NSObject<br class="">- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;<br class="">@end<br class=""><br class="">This is because the Obj-C declarations are all at the top level (as Obj-C does not have nested types), so a type that is clearly unambiguous in Swift may become ambiguous in Obj-C. As a trivial example, the following Swift code:<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="">class Baz: NSObject {<br class=""> @objc enum Bar: Int {<br class=""> case Apple, Orange<br class=""> }<br class="">}<br class=""><br class="">is currently exported to Obj-C as:<br class=""><br class="">SWIFT_CLASS("_TtC7unnamed3Baz")<br class="">@interface Baz : NSObject<br class="">- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;<br class="">@end<br class=""><br class="">typedef SWIFT_ENUM(NSInteger, Bar) {<br class=""> BarApple = 0,<br class=""> BarOrange = 1,<br class="">};<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="">This is attempting to redefine the type Bar, which is of course problematic.<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></div></div></blockquote></div><br class=""></body></html>