Swift Pitch: Observation
There are already a few mechanisms for observation in Swift. Some of these include Key Value Observing (KVO), or
ObservableObject; but those are relegated to in the case of KVO to justNSObjectdescendants, andObservableObjectrequires using Combine which is restricted to Darwin platforms and does not leverage language features like async/await orAsyncSequence. By taking experience from those existing systems we can build a more generally useful feature that applies to all Swift reference types; not just those that inherit fromNSObjectand have it work cross platform with using the advantages from low level language features like async/await.[…]
Combine’s
ObservableObjectproduces changes on the leading edge of the will/did events and all delivered values are before the value did set. Albeit this serves SwiftUI well, it is restrictive for non SwiftUI usage and can be surprising to developers first encountering that restriction.[…]
The
Observableprotocol includes a set of extension methods to handle observation. In the simplest, most common case, a client can use thechanges(for:)method to observe changes to that field for a given instance. […] This allows users of this protocol to be able to observe the changes to specific values either as a distinct step in the chain of change events or as an asynchronous sequence of change events.[…]
By default the concept of observation is transitively forwarded; observing a keypath of
\A.b.c.dmeans that if the field.bisObservablethat is registered with an observer to track\B.c.dand so on. This means that graphs of observations can be tracked such that any set of changes are forwarded as an event.[…]
The
ObservationTrackingmechanism is the primary interface designed for the purposes to interoperate with SwiftUI. Views will register via thewithTrackingmethod such that if in the execution ofbodyany field is accessed in anObservablethat field is registered into the access set that will be indicated in the handler passed to theaddChangeHandlerfunction. If at any point in time that handler needs to be directly invalidated theinvalidatefunction can be invoked; which will remove all change handlers registered to theObservableinstances under the tracking.[…]
A default implementation can be accomplished in generality by a type wrapper that intercepts the modifications of any field on the
Observable. The type wrapperDefaultObservableprovides default implementations for the type where the associatedObservationtype isObservationTracking.Token. This means that developers have the flexibility of an easy to use interface that progressively allows for more and more detailed control: starting from mere annotation that grants general observability, progressing to delegation to a storage mechanism that manages registering and unregistering observers, to full control of observation.
There’s a number of issues we ran into with KVO, all around concurrency[…]
Philippe’s new
ObservationTrackingmachinery reads like a shippable spiritual successor to that hack.
Update (2023-03-20): Philippe Hausler:
- Pitch 1: Initial pitch
- Pitch 2: Previously Observation registered observers directly to
Observable, the new approach registers observers to anObservablevia aObservationTransactionModel. These models control the “edge” of where the change is emitted. They are the responsible component for notifying the observers of events. This allows the observers to focus on just the event and not worry about “leading” or “trailing” (will/did) “edges” of the signal. Additionally the pitch was shifted from the type wrapper feature over to the more appropriate macro features.- Pitch 3: The
Observerprotocol andaddObserver(_:)method are gone in favor of providing async sequences of changes and transactions.
Update (2023-04-21): Ben Cohen:
The review of SE-0395: Observability begins now and runs through April 24, 2023.
1 Comment RSS · Twitter
Considering this comment from the proposal’s author/implementor, I think this proposal will be returned for revision and undergo another review.