<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I find more limiting the ability not to declare @objc a property of a class that doesn't inherit from NSObject:<div class=""><br class=""></div><div class="">class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var x: Int = 0</div><div class="">}</div><div class=""><br class=""></div><div class="">class Bar {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var foo = Foo() // Why shouldn't we allow this @objc? </div><div class="">}</div><div class=""><br class=""></div><div class="">or</div><div class=""><br class=""></div><div class="">protocol BarProtocol: AnyObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func fooDidBar(_ foo: Foo)</div><div class="">}</div><div class=""><br class=""></div><div class="">class BarContoller: NSViewController {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@IBOutlet weak var delegate: BarProtocol? // Error - not expressible in ObjC.</div><div class="">}</div><div class=""><br class=""></div><div class="">While Foo doesn't inherit from NSObject, it still can have @objc members used for binding. I have quite few classes that need to inherit from NSObject just for that purpose.</div><div class=""><br class=""></div><div class="">I fully understand the logic behind it that it needs to be exported to ObjC headers and runtime metadata, but I'd prefer these being exported as (id) into ObjC rather than not allowing this at all as these are all objects that can be passed into the ObjC world...</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 8:49 PM, Riley Testut 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">Hi Swift-Evolution,<div class=""><br class=""></div><div class="">Back when SE-0057 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md</a>) was proposed, it included the following passage:</div><div class=""><br class=""></div><div class=""><ul style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; padding-left: 2em;" class=""><li style="box-sizing: border-box;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">The generic type parameters in Swift will always be class-bound, i.e., the generic class will have the requirement <code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">T : AnyObject</code>.</span></li></ul><div class="">This made sense at the time, since Swift <-> Objective-C interoperability was only possible with class types (AnyObject). However, several months after SE-0057 was accepted, SE-0116 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md</a>) was accepted, which allowed for bridging <i class="">any</i> type to Objective-C, not just class types.</div><div class=""><br class=""></div><div class="">This greatly improved interoperability between Swift and Objective-C code, but the AnyObject restriction on Objective-C generics remained. This issue is especially apparent when using lesser-known Objective-C collection types such as NSCache, where it may make sense to store value types or use value types as the keys, but the compiler does not allow it.</div></div><div class=""><br class=""></div><div class="">I propose that this restriction is lifted, and that generic Objective-C parameters are no longer restricted to conforming to AnyObject. I’m assuming this is not as straightforward as it might seem at first to implement, but I think the benefits would make the effort worth it, since this seems like an overlooked case and not intentionally kept this way.</div><div class=""><br class=""></div><div class="">Thoughts?</div></div>_______________________________________________<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></blockquote></div><br class=""></div></body></html>