[Pitch] Transactional observation of values

[vanvoorden (Rick van Voorden)]

@Philippe_Hausler

Observing at the next suspension point means that we can also address the second issue too; sharing. The expectation of observing a property from a type as an AsyncSequence is that multiple iterations of the same sequence from multiple tasks will emit the same values at the same iteration points.

One of the questions about concurrency I see a lot is strategies for deterministic and predictable tests. Will product engineers building against Observed be able to make any kind of safe assumptions about any "backpressure" — or the absence of backpressure — on the delivery of values?

Could there be support for product engineers "injecting" their own custom AsyncSequence type to be used to deliver values? Or would Observed have to be locked down to its own private AsyncSequence type? Would product engineers have to look for another direction if they want to inject another AsyncSequence type?

Writing testable UI related code with modern Swift

Hello, I am trying to understand how I can migrate some of my older Combine /ObservedObject/Quick/Nimble based code to modern async/Observable/Swift Testing code but am running into problems with even very simple situations. I hope I am missing something obvious and would appreciate any insights. We follow an MVVM pattern for testability's sake. While I know SwiftUI encourages you to put far more code in the view itself, we've found this makes it far harder (or even impossible) to test as thoro…