> On Nov 8, 2017, at 10:51 PM, Charlie Monroe via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 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? 
> }
> or
> protocol BarProtocol: AnyObject {
>       func fooDidBar(_ foo: Foo)
> }
> class BarContoller: NSViewController {
>       @IBOutlet weak var delegate: BarProtocol? // Error - not expressible in 
> ObjC.
> }
> 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...

+1000. In addition to the issues raised above, this limitation wreaks havoc 
with my attempts to properly support KVO in Swift projects. You either have to 
create a second Any-typed property, bloating the interface, or you have to go 
with the old string-based key path API, which also locks you out of using the 
Swift 4 closure-based observers.


swift-evolution mailing list

Reply via email to