Declare AnyAsyncSequence Sendable when its elements are

[lhoward]

Description

AnyAsyncSequence stores nothing but a @Sendable closure, and init(_:) already requires the erased base to be Sendable, so the type is safe to send whenever its elements are. Without a declared conformance, consumers compiling in the Swift 6 language mode cannot return an erased sequence from an actor, store one in a Sendable type, or merge erased sequences and erase the result again; each is diagnosed as sending a non-Sendable value. This adds

extension AnyAsyncSequence: @unchecked Sendable where Element: Sendable {}

@unchecked because the compiler cannot see through the closure; the closure's own @Sendable requirement is what makes it sound. AnyAsyncIterator is left alone: it holds a mutable base and is not meant to be shared.

Tests

No behaviour change. On this machine (Linux, Swift 6.4) the package only compiles with #70 applied, so I confirmed the change builds and the suite passes on top of #70 and #71 (199 tests, 0 failures); on its own it is a four-line source change with no dependencies on either.

Checklist

• this PR is based on the main branch and is up-to-date
• the commits inside this PR have explicit commit messages
• unit tests cover the new feature or the bug fix (compile-time conformance only)
• the CHANGELOG is up-to-date (can add an entry if wanted)

🤖 Generated with Claude Code

https://claude.ai/code/session_01T8cahEd4GfsHQ89sNrmP4p

[twittemb]

Closing because this conformance is already present on current main: extension AnyAsyncSequence: Sendable {} in Sources/Operators/AsyncSequence+EraseToAnyAsyncSequence.swift.

The existing conformance is compiler-checked and unconditional, so the additional conditional @unchecked Sendable conformance here is redundant. Linux compatibility has also been delivered by merged PR #74: #74, with passing Linux CI on Swift 6.1.3 and 6.4.0.