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

[David Waite]

> On Jun 22, 2016, at 7:12 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jun 22, 2016, at 6:41 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Wed Jun 22 2016, Matthew Johnson <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> On Jun 22, 2016, at 3:57 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I believe this is a problem that should be solved.  
>>> 
>>> I also believe distinguishing between finite and infinite sequences is
>>> a good idea (along with preventing for..in from being used with an
>>> infinite sequence)
>> 
>> for..in over an infinite sequence is not necessarily wrong.  I'm not
>> confident it should be prevented.  It's certainly less dangerous than
>> using `forEach`, from which there is no possibility of escape.
> 
> Sure, it’s not wrong in the sense that sometimes an infinite loop is valid.  But I think it would almost always be wrong (an accident) in practice.  If you really want to loop over an infinite sequence maybe it’s a good thing to require you to do that explicitly.
The problem is that the only way to know a loop is infinite reliably is to have the developer opt-in. 

Also, operations on said infinite sequence might or might not be infinite - a Fibonacci sequence.first { $0 == 0 } would go forever since the sequence starts with 1 and never decreases.

Then we have the issue that we have finite sequences which will still take longer than the typical hardware lifetime.

let x = 0..<Int.max #9223372036854775806
foo(1..<Int.max) # even if foo contains a loop which evaluates a billion elements a second, will take ~292 years to complete

In UI programming unintentionally expensive operations are easier to detect since the runloop forms a natural watchdog. This is how spinning beachballs are born.

>> That's not an over-constraint.  Multi-pass-ness *is* the fundamental
>> distinction between Sequence and Collection.  AFAIK there's no multipass
>> sequence that cannot support indices.

That indices are expected to be O(1) in Collection (under penalty of documentation and/or surprise) means that there is an impact above just implementing an Iterator for implementing a Collection, is there not?
> 
>> 
>> FWIW, I'm also not entirely confident that single-pass things should be
>> part of *this* picture at all.  It might be that single-pass things
>> should be entirely separate and forced to be reference types where
>> traversal mutates the instance.  
> 
> This seems like a reasonable direction.
> 
>> E.g., the current Iterator could gain a
>> class constraint and become the only representation of single-pass
>> sequences.
> 
> Hmm.  I would have to give this more thought.  Do we really want to require all conformances of `Iterator` to be reference types?  What would be the performance impact of that?

I am also unclear here - are you talking of moving the current functionality used for Iterator someplace else, or creating a new SinglePassIteratorProtocol?  

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160622/8b7908bd/attachment.html>