[WithLatestFrom] implement operator for arity 1 and 2

[twittemb]

Hi.

This PR aims to propose a new operator: withLatest(from:). It has been discussed in the forum here.

I am new to the evolution proposal process. This PR contains:

• a proposal based on the sample + the guides.
• the implemented operator with unit tests and documentation.

Don't hesitate to guide me through the process 😀.

Thanks.

[parkera]

Marking this as v1.1 because we should strongly consider it after our initial API stable 1.0 release.

[twittemb]

Just left some smaller comments here already that I spotted

Hi @FranzBusch thanks for the review. I'll address them soon. As for the "ad-hoc" internal testing properties, I followed some advices given in this thread by Joe Groff (https://forums.swift.org/t/reliably-testing-code-that-adopts-swift-concurrency/57304/32). Testing concurrently executing code involving a time line is really challenging. In the case of withLatest(from:) we have to have a precise coordination that is deterministic because we have no control on the inner task execution for the other sequence.

What would you suggest to improve that ?

[FranzBusch]

Hi @FranzBusch thanks for the review. I'll address them soon. As for the "ad-hoc" internal testing properties, I followed some advices given in this thread by Joe Groff (https://forums.swift.org/t/reliably-testing-code-that-adopts-swift-concurrency/57304/32). Testing concurrently executing code involving a time line is really challenging. In the case of withLatest(from:) we have to have a precise coordination that is deterministic because we have no control on the inner task execution for the other sequence.

What would you suggest to improve that ?

I am really torn on that suggestion, but I feel your pain points because I experienced the same in the merge and debounce implementation where certain scenarios can't be tested since you are not controlling the flow in the spawned Tasks. I think if we go forward with hooks for tests we should #if DEBUG to only have them in the tests but even that produces problems since we want to run the benchmarking tests in release mode.

I would like to get @phausler opinion here about test hooks for simulating timings.

[phausler]

So we can control the spawning of tasks! https://github.com/apple/swift-async-algorithms/blob/main/Sources/AsyncSequenceValidation/Test.swift#L313 is where the tests do it today - and I could imagine that we could add either extra functionality to that to adjust the way we need... or we can use that dark magic to build some other really neat tools to control that in different ways.

What I think would be a good plan is to favor testing via what is public surface area as much as possible and then collect info on exactly what we need such that either a) we can get effort from a language/runtime layer or b) (ab)use some of the runtime functions to manipulate the execution into what we want to test. But that really requires some really good outlines of precisely what needs to occur in the most general sense.