Reapply #87698 and fix overload resolution for Sequence+AsyncSequence types.#88442
Reapply #87698 and fix overload resolution for Sequence+AsyncSequence types.#88442clintonpi wants to merge 2 commits intoswiftlang:mainfrom
Conversation
…wiftlang#87698)" (swiftlang#88269) This reverts commit 8a51f7a.
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
Since generalizing Sequence methods for typed throws, the overload resolution prefers the corresponding AsyncSequence methods which cannot be generalized yet. To fix this, all rethrowing Sequence methods (except withContiguousStorageIfAvailable) were duplicated in a new extension (`extension AsyncSequence where Self: Sequence`).
clintonpi
force-pushed
the
async-sequence-typed-throws-generalization
branch
from
fd496a6 to
c3e2873
Compare
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
phausler
left a comment
phausler
left a comment
There was a problem hiding this comment.
This approach looks good; what does it mean for when we do further typed throws support for async sequence?
|
If the support is back-deployed covering SwiftStdlib 5.1, then these duplicates can be safely deleted with no source breakage. Else, they'll have to stay in place and be annotated as obsolete. |
|
Also, if the duplicates were somehow forgotten and co-exist with the future AsyncSequence typed-throwing methods, other things being equal, the future typed-throwing ones will be picked where the current rethrowing ones are picked. |
|
Unimportant nit: "stdlib/public/Concurrency/AsyncSequence.swift" could use an updated year range in the copyright header. |
3 participants
Since generalizing Sequence methods for typed throws, the overload resolution prefers the corresponding AsyncSequence methods which cannot be generalized yet. To fix this, all rethrowing Sequence methods (except withContiguousStorageIfAvailable) were duplicated in a new extension (
extension AsyncSequence where Self: Sequence).