Skip to content

Conversation

@Azoy
Copy link
Contributor

@Azoy Azoy commented Nov 3, 2025

This is a work in progress, but should be enough to get borrowing for in syntax to work.

Azoy and others added 4 commits November 3, 2025 13:43
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.
@airspeedswift
Copy link
Member

@swift-ci build toolchain

@airspeedswift
Copy link
Member

@airspeedswift
Copy link
Member

@airspeedswift
Copy link
Member

///
/// This sequence is consumed when its generator is advanced.
public struct MinimalSequence<T> : Sequence, CustomDebugStringConvertible {
public typealias Element = T
Copy link
Contributor

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

Copy link
Member

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)

Copy link
Member

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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants