[SR-9498] Observing an object's protocol crashes, while observing the object directly works

[swift-ci]

Previous ID	SR-9498
Radar	None
Original Reporter	JeffreyEarly (JIRA User)
Type	Bug

Additional Detail from JIRA

Votes	0
Component/s	Foundation
Labels	Bug, KeyPaths
Assignee	None
Priority	Medium

md5: 1848302fc9a5554dbe3251cbc7003e87

Issue Description:

It looks like you can not observe NSObjects with protocols, even if the underlying class can be observed directly.

import Foundation

protocol Enabled {
    var isEnabled: Bool {get set}
}

class C: NSObject, Enabled {
    @objc dynamic var isEnabled: Bool = false
}

let c = C()

func observeMeDirectly(_ object: C) {
    let _ = object.observe(\.isEnabled, options: [.new]) { _, _ in
        print("changed")
    }
}

observeMeDirectly(c)
// this works fine

func observeMyProtocolType<T>(_ object: T) where T:Enabled, T:NSObject {
    let _ = object.observe(\.isEnabled, options: [.new]) { _, _ in
        print("changed")
    }
}

observeMyProtocolType(c)
// this fails

This looks different than the other related bugs I've found in the tracker, but I'm not sure.

[belkadan]

I think this is correct behavior because the protocol's property isn't @objc. That is, someone else could implement the protocol and subclass NSObject without exposing the property to Objective-C. You can make the protocol @objc to fix this.

Leaving open to potentially improve the error message:

Fatal error: Could not extract a String from KeyPath Swift.WritableKeyPath<main.C, Swift.Bool>: file /Volumes/Data/swift-public/swift/stdlib/public/SDK/Foundation/NSObject.swift, line 91

[swift-ci]

Comment by Jeffrey J. Early (JIRA)

Yes, that makes perfect sense. Thank you.