-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[stdlib] Add a new Iterable protocol with a BorrowIteratorProtocol #85294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This change allows noncopyable and nonescapable Sequence types, with room for generalizing the Element type to be ~Copyable in the future. The new prototype adds a BorrowingIterator associated type to Sequence This commit adds a BorrowingIteratorProtocol for generalized bulk iteration, a BorrowingIteratorAdapter as an implementation of the new Sequence requirement for existing sequences, and a NeverIterator for new noncopyable/nonescapable sequence types. Conformance to Sequence for Span and InlineArray is also included. Issues: - Availability checking must be off due to the availability requirements on the new Sequence.BorrowingIterator associated type - Several existing sequences needed an explicit Element type alias to compile (note that this was during experimentation, so it may be possible to back out these changes) - Some of the default implementations for generalized sequences simply fatal error - InlineArray is a tricky case, due to its conditionally copyable design. It conforms to Sequence unconditionally, so it needs an unconditional implementation of (the original) Iterator associated type. However, when Sequence can use ~Copyable elements, that implementation won't be workable, since (a) it copies the inline array, and (b) it implements the `next() -> Element?` method, which can't return a noncopyable element.
3f4c9f7 to
a9ff08d
Compare
|
@swift-ci build toolchain |
|
with swiftlang/swift-experimental-string-processing#843 |
|
with swiftlang/swift-experimental-string-processing#843 |
|
with swiftlang/swift-experimental-string-processing#843 |
| /// | ||
| /// This sequence is consumed when its generator is advanced. | ||
| public struct MinimalSequence<T> : Sequence, CustomDebugStringConvertible { | ||
| public typealias Element = T |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it might be worth just renaming the generic parameter T to Element, for readability in any case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would agree... except that it was actually useful that this caught something that stopped working for other reasons (which I guess means we should have test instead)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would consider this PR probably not landable until this type alias is no longer needed...
Because the BorrowingIteratorAdapter type still required Copyable elements, it was failing to be allowed as the default BorrowIterator type for any sequences. However, just marking the `Iterator.Element` type as `~Copyable` is impossible, since IteratorProtocol has a copyable element type, and switching to being generic over a sequence with a noncopyable element type fails with this error: Cannot suppress '~Copyable' on generic parameter 'S.Element' defined in outer scope This change resolves things by adding `Element: ~Copyable` as a second generic parameter and equating the new type and `Iterator.Element`.
This is a work in progress, but should be enough to get borrowing
for insyntax to work.