What is your evaluation of the proposal?
Supportive. Some reservations about details:
ObservationTracking.Event/matches(_:)will have subtle and unintuitive behavior when a client is accessing an observable object via computed properties (more complete example from the pitch thread); the proposed API results in changes in behavior on the client end if an observed object’s property changes from stored to computed (which is API- and ABI-compatible today, and to my understanding is intended to be opaque to clients)ObservationTracking.Event/matches(_:)operating atKeyPathgranularity limits its ability to disambiguate between changes: an observation tracking closure which references multipleObservableobjects of the same type cannot determine which of the observed objects changed, only which property did- This function seems to best support simple object graphs (or more precisely, those where each type has one instance, or few enough that disambiguations is unnecessary)
- Not novel to this proposal: new APIs with
@_inheritActorContextclosures are thorny as a developer, because this underscored attribute is largely hidden to developers but the behavior difference is essential to understanding the puzzle of attributes that affect the isolation with which a closure is run
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. “How do I observe didSet?” has been a frequently asked developer question since the introduction of Observable, and offering differently shaped tools to address that question expands the “free” value of @Observable.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Engagement in the pitch thread; a quick re-read now.