[swift-evolution] [Pitch] Remove destructive consumption from Sequence

[Dave Abrahams]

on Mon Jun 27 2016, Anton Zhilin <swift-evolution at swift.org> wrote:

> Dave Abrahams via swift-evolution <swift-evolution at ...> writes:
>
>> I should be clear up-front about the main problem I'm trying to solve:
>> 
>> Today, people see a beautiful, simple protocol (Sequence) to which many
>> things conform. They don't recognize that there's a semantic restriction
>> (assume you can make only a single-pass!) on it, so they write libraries
>> of functions that may make multiple passes over Sequences.  They test
>> their libraries with the most commonly-available Sequences, e.g. Arrays
>> and Ranges, which happen to be multi-pass.  Their tests pass!  But their
>> constraints are wrong, their whole model of how to write generic code
>> over sequences is wrong, and some of their code is wrong.
>
> This is a mistake that I see more often than I want to: designers of 
> development tools underestimate abilities of developers, and end up 
> restricting many of them.

In what way am I underestimating the abilities of developers?

> My point is that we should impose minimal requirements on custom data
> types. Quoting yourself:
>
>> In this case, protocols used to interface with the language
>> at the lowest levels may be purely about syntax.
>
> So there should be a protocol for building into for-in loops that 
> requires only that the sequence should be iterable once. Currently, we 
> have Sequence for that. If we remove destructive consumption from 
> Sequence, then there should be a super-protocol SinglePassSequence or 
> Forinable (excuse the pun).

Yes.

> But even if we do this, I still don't understand the intentions. If a
> Sequence is multi-pass, then we can satisfy requirements of
> Collection, as already noted in the discussion. Why should we keep
> Sequence at all, then? Then let's remove it and rename
> SinglePassSequence to Sequence???

This kinds of decisions are all part of the discussion.

-- 
Dave