SE-0475: Transactional Observation of Values

Evolution Proposal Reviews
69

I know I'm (too!) late to the party, but I had cause to look deeper into this recently and I realized a couple things:

  • As discussed in the ProgressReporter thread, the current implementation has a shortcoming where if withObservationTracking discovers that the emit closure observes no properties (and will therefore never be run again) the sequence does not finish.
  • As discussed in the ProgressReporter thread, withObservationTracking inherently creates a window where concurrent changes are not tracked. Observation really wants to be able to guarantee that Observable types are either global-actor-isolated or non-Sendable, which the type system can't represent.
  • withObservationTracking doesn't provide an option to cancel an established observation. This sequence actually mitigates this somewhat because you can cancel the iterating task, but it's still the case that a long-lived object which many people begin observing, but which never changes, leaks memory through an ever-increasing set of observations and lookups.

I don't see how to avoid the latter two issues without a replacement for withObservationTracking that creates a persistent observation (avoiding windows where concurrent mutations aren't tracked), and allows that observation to be explicitly cancelled (freeing up its resources on the observed objects).

2 Likes