The new one is smart enough to figure out a type witness for
AsyncSequence.Failure from AsyncSequence.AsyncIterator.Failure, but the
old one doesn't have general logic to handle cases like these. Introduce
a bespoke rule to keep the old/new associated type inference logic in
sync for the newly-introduced Failure type.
When inferring a type witness for `AsyncIteratorProtocol` or
`AsyncSequence`'s `Failure` associated type, don't infer from a
generic parameter named `Failure`. Instead, use `next()` as a cue: if
it `rethrows`, use `Failure` from one of the conformances; if it
`throws`, use `any Error`. This is a more conservative inference rule,
and addresses a failure to infer a `Failure` type witness for some
fairly-obvious cases.
Fixes rdar://122514816.
This couples together several changes to move entirely from
`@rethrows` over to typed throws:
* Use the `Failure` type to determine whether an async for-each loop
will throw, rather than depending on rethrows checking
* Introduce a special carve-out for `rethrows` functions that have a
generic requirement on an `AsyncSequence` or `AsyncIteratorProtocol`,
which uses that requirement's `Failure` type as potentially being part
of the thrown error type. This allows existing generic functions like
the following to continue to work:
func f<S: AsyncSequence>(_: S) rethrows
* Switch SIL generation for the async for-each loop from the prior
`next()` over to the typed-throws version `_nextElement`.
* Remove `@rethrows` from `AsyncSequence` and `AsyncIteratorProtocol`
entirely. We are now fully dependent on typed throws.
Introduce a new associated type `Failure` into the two protocols involved
in async sequences, which represents the type thrown when the sequence
fails. Introduce a defaulted `_nextElement()` operations that throws
`Failure` or produces the next element of the sequence. Provide a
default implementation of `_nextElement()` in terms of `next()` that
force-cases the thrown error to the `Failure` type.
Introduce special associated type inference logic for the `Failure`
type of an `AsyncIteratorProtocol` conformance when there is no
specific _nextElement()` witness. This inference logic looks at the
witness for `next()`:
* If `next()` throws nothing, `Failure` is inferred to `Never`.
* If `next()` throws, `Failure` is inferred to `any Error`.
* If `next()` rethrows, `Failure` is inferred to `T.Failure`, where
`T` is the first type parameter with a conformance to either
`AsyncSequence` or `AsyncIteratorProtocol`.
The default implementation and the inference rule, together, allow
existing async sequences to continue working as before, and set us up
for changing the contract of the `async for` loop to use
`_nextIterator()` rather than `next()`.
Give `AsyncSequence` and `AsyncIteratorProtocol` primary associated
types for the element and failure types, which will allow them to be
used more generally with existential and opaque types.
