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

[Dave Abrahams]

on Fri Jul 01 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

>> On Jul 1, 2016, at 9:47 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Fri Jul 01 2016, Haravikk <swift-evolution-AT-haravikk.me> wrote:
>> 
>
>>>> On 30 Jun 2016, at 23:39, Dave Abrahams <dabrahams at apple.com> wrote:
>>>> All multi-pass sequences can benefit from subscripts.
>>> 
>>> Sorry, not really what I meant, but rather; how many sequences are
>>> really going to use them?
>> 
>> The subscript and index aren't there for the sequence's benefit, and you
>> can't know how users will want to use the sequence.  The whole point of
>> making a type conform to a generic protocol is that you can't anticipate
>> all of the type's uses, so you want to make it work with as much other
>> code as possible.  If I'm defining a new sequence type, how can I know
>> whether someone might want to use index(of:) or slicing on it?
>
> This isn’t entirely true.  Sometimes we know *exactly* how a type will
> be used in an application.  It conforms to a generic protocol in order
> to take advantage of pre-existing generic code (algorithms, etc) in
> the standard library (or other libraries).
>
> If the library contains algorithms expressed in terms of the weakest
> constraints possible (i.e. the current `Sequence` algorithms)
> sometimes we can accomplish what is necessary without needing to
> implement additional members on our type, even if it is possible to
> implement them and theoretically useful (but not useful to the current
> requirements of the application).

Yes, but requirements clustering is absolutely essential to creating
coherent generic libraries.  Otherwise you end up with a billion little
granular protocols, to no real purpose.

> That said, I generally like the direction you suggesting.  
>
> I have been considering the incremental complexity of conforming to
> `Collection` rather than `Sequence` carefully.  The one place that I
> still need to think further about is the `Comparable` requirement on
> indices and whether that might lead to nontrivial complexity over a
> `Sequence` conformance.

It might, but let's drop it.  The only *real* reason we have it is to
provide nice precondition checking for Range construction, and we can
simply make that conditional on comparability.

-- 
Dave