Whoops. If anyone would know this problem, it's you, Lily! @Catfish-Man, this wasn't intentional, was it?

Last night I whipped up a fix for this (and for the other issues I filed), but I haven't tested it yet. I would really like to know what the radar says though.

The original bug was an error message when using override:

/Users/david/swift/swift/stdlib/public/SDK/Foundation/NSObject.swift:148:25: error: method cannot be marked @objc because the type of the parameter 3 cannot be represented in Objective-C
    @objc override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
                        ^

This would have been a compiler bug at the time, and it also definitely suggests that we weren't trying to swizzle NSObject's implementation. The workaround:

Ah, since you're going to swizzle it /anyway/, you could use [NSString: Any] for now. NSString and NSKeyValueChangeKey will always have the same ABI.

The Radar itself is now marked as Verify, by me, so maybe we can just go back to the simple thing?

What happens if you simply omit the @objc keyword? Isn't it supposed to be inferred in the case of an override anyway?

I did notice the stdlib seems to be using explicit @objc and @nonobjc keywords everywhere. Is Obj-C compatibility inferred differently for the stdlib than for other code?

You're right about @objc being inferred; it shouldn't have any effect here. I think the explicit-ness was mostly for the transition from Swift 3 to Swift 4, where the default behavior flipped, and it's stuck as the style to demonstrate that people have thought about it.

I would definitely like to remove the workaround if we can!

That said, iirc the swizzling was intentional (sorry, it's been a bit since I wrote this). The case it was trying to handle is when a class hierarchy has a mix of objc-style and swift-style KVO, to make sure that each observation callback is "visible" to both. So the ObjC ones bubble up the class hierarchy, and then the Swift ones get invoked, and then if nobody handled it it crashes as usual. Crashing in that bogus a way was definitely not the intent though, and it's certainly possible I got something else about it wrong.

@Catfish-Man It sounds like you're describing the swizzling for NSKeyValueObservingCustomization. This ticket is about the swizzling on NSKeyValueObservation specifically, which is different.

And that's what I get for commenting with a headache and not thinking clearly 🙂

In that case, yes, kill it with fire if the compiler allows now

FWIW looks like the compiler bug is not yet fixed. Omitting the @objc still produces the same error that you get if you include it, which is that the method signature isn't compatible with Obj-C.

I've submitted PR #20103 for this issue.

Merged: apple/swift@7c51419