cc @millenomi

I've got a proof-of-concept patch done already, but I haven't attempt to test it yet. I'm not sure how to even try and write tests for race conditions involving code that is executed once per process.

Also, while writing this, I determined that even the per-thread approach isn't a complete solution. If the implementation of automaticallyNotifiesObservers(for:) itself creates any observations (or NSSortDescriptor or NSExpression using KeyPath) then this can overwrite the per-thread value before keyPathsAffectingValue(for:) is invoked. This is of course a pretty esoteric edge case, but I don't see any way to solve it.

That said, I think the whole protocol is fundamentally flawed and should be removed. I will be filing a separate ticket about that.

I filed the issue SR-9081 about how we should just remove the protocol entirely.

@swift-ci create

API can't be removed; we have to fix this.

It looks to me like the solution here is either a per-thread table; or just add type information to the global table (e.g.: )

String(describing: type(of: keyPath).rootType)

Type information doesn't work in the face of subclasses. See SR-9081 for more details. The protocol is fundamentally broken.

I've submitted PR #20103 for this issue.

This PR implements the per-thread table approach. It occurs to me just now that the above esoteric edge case could be solved by having the stubs that invoke the NSKeyValueObservingCustomization methods reinstall the key path after invoking the method. I'll probably update the PR to do that.

Upon reflection, reinstalling the key path won’t work if a subclass (or the class itself) overrides the Obj-C method and uses key paths there. This will overwrite the key path table before our stub is even invoked.

I’ve also just realized that the protocol itself is broken in the case where someone uses the Obj-C observation method because we won’t have an opportunity to populate the key path table to begin with.

Merged: apple/swift@7c51419