I find more limiting the ability not to declare @objc a property of a class 
that doesn't inherit from NSObject:

class Foo {
        var x: Int = 0

class Bar {
        var foo = Foo() // Why shouldn't we allow this @objc? 


protocol BarProtocol: AnyObject {
        func fooDidBar(_ foo: Foo)

class BarContoller: NSViewController {
        @IBOutlet weak var delegate: BarProtocol? // Error - not expressible in 

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.

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...

> On Nov 8, 2017, at 8:49 PM, Riley Testut via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Hi Swift-Evolution,
> Back when SE-0057 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md
> <https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md>)
>  was proposed, it included the following passage:
> The generic type parameters in Swift will always be class-bound, i.e., the 
> generic class will have the requirement T : AnyObject.
> 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 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md
> <https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md>)
>  was accepted, which allowed for bridging any type to Objective-C, not just 
> class types.
> 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.
> 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.
> Thoughts?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to