SE-0475: Transactional Observation of Values

[jamieQ (Jamie)]

as i've found myself somewhat mentally involved with this feature, i'll endeavor to respond to these:

@KeithBauerANZ

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.

i raised this in the pitch thread, and it was deemed to be 'pretty much a case of bad input yielding bad results', and providing feedback that this may have occurred was deferred as a possible 'future enhancement'. seems like it is a thing that will (and probably does) happen in practice to me though.

@KeithBauerANZ

As discussed in the ProgressReporter thread, withObservationTracking inherently creates a window where concurrent changes are not tracked.

i think a kind-of related question was also covered in the linked posts above, and my reading of the response is that it's the clients' responsibility to ensure there's no 'tearing' potential for any Sendable values. IIUC though, the point you surfaced is a bit of a deeper issue with the current implementation of withObservationTracking, in that the access tracking and tracking installation are perhaps not themselves 'transactional' and may miss changes to tracked values that occur in-between the generation of the access information and the installation of the onChange handler. that seems like a problem.

@KeithBauerANZ

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.

this was also noted weeks ago on the implementation PR, but the PR has now been merged without that seemingly having been addressed.