> 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.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
