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

[Dave Abrahams]

on Mon Jun 27 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

>> On Jun 26, 2016, at 10:56 PM, Jonathan Hull via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> Can’t a Sequence be potentially infinite, whereas a collection has a
>> defined count/endIndex?  Other than that, I agree with your
>
>> statement.
>> 
>> Here is what I see as the appropriate structure:
>> 
>> Iterator: Single destructive pass, potentially infinite, (should be for-in able)
>> Sequence: Guaranteed non-destructive multi-pass (vends Iterators),
>> potentially infinite, (should be subscript-able, gain most of
>> collection, but lose anything that relies on it ending)
>> Collection: Multi-pass, guaranteed finite, (no changes from current
>> form, except extra inits from Iterator/Sequence with end conditions)
>> 
>> Right now we are allowed to have an infinite sequence, but calling
>> dropLast or non-lazy map will cause an infinite loop.  These cases
>> could be made much safer by considering the potentially infinite and
>> finite cases separately…
>
> I think this is pointing in the right general direction.  It would
> make working with `Sequence` much more straightforward and allow us to
> depend on the multi-pass property that is true in practice of the most
> common models of `Sequence`.
>
> But I agree that we should give much more careful consideration to
> finite / infinite generally and for..in specifically.
>
> Now that I have been thinking about the finite / infinite distinction
> more closely I have begun to notice a lot of code that is written
> generically using `Sequence` where a for..in loop is really what is
> required, however the “finite sequence” precondition is not explicitly
> stated.  Interestingly, this is the case with the standard library’s
> eager `map` (but not the case with `dropLast` which explicitly notes
> the precondition).  I have been somewhat surprised to realize how
> common this “bug” is (i.e. not stating a precondition).  I think we
> have gotten away with it thus far because the sequences most people
> use most of the time in practice are finite.  But that doesn’t mean we
> should accept this as good enough - IMO it is way to easy to forget to
> document this precondition (and obviously easier for users to overlook
> than preconditions that are actually encoded in the type system,
> violations of which are caught at compile time).
>
> The fact that this pattern is so pervasive is what I meant when I said
> for..in “naturally” requires a finite sequence.
>
> IMO it’s better to encode preconditions in the type system when that
> is practical, and especially when the precondition is shared by a vast
> majority of code written using a particular construct (in this case a
> for..in loop written using the most generic for..in-able protocol).
>
> I think the safest solution is to take the position that writing an
> infinite loop is relatively uncommon and is a more “advanced”
> technique, and thus should be done explicitly.  Do people really write
> infinite loops often enough that the convenience of using for..in when
> writing infinite loops outweighs the safety benefit of preventing
> accidental infinite loops?  I haven’t seen a compelling argument for
> this.

Good questions.  I'd also add: “do infinite sequences come up often
enough that accidentally looping on them forever is a problem?”

> If we adopt that position then for..in would need to be built on top
> of a guaranteed finite construct.  This would allow programmers to
> continue writing generic code agains the most generic for..in-able
> construct while eliminating a precondition that is often (usually?)
> unstated and likely unconsidered.
>
> If we do decide to move forward with infinite for..in loops I think we
> need to establish strong guidance around how to properly write generic
> code with these protocols.  Should such code really be constrained to
> `Collection` rather than `Sequence` (i.e. should a potentially
> infinite `Sequence` have an eager map)?  If this is the guidance,
> should it be paired with guidance that all finite sequences should
> conform to `Collection`?  Or is it sufficient to just educate
> developers about this issue and expect people to document the “finite
> Sequence” precondition when the constraint is `Sequence` rather than
> `Collection`?
>
> I hope we will give serious consideration to these questions while
> this topic is open for discussion.
>
> -Matthew
>
>> 
>> Thanks,
>> Jon
>> 
>>> on Wed Jun 22 2016, David Waite <david-AT-alkaline-solutions.com
>>> <http://david-at-alkaline-solutions.com/>> wrote:
>>> 
>>> >> On Jun 22, 2016, at 2:57 PM, Dave Abrahams via swift-evolution
>>> >> <swift-evolution at swift.org
>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>>
>>> >> wrote:
>>> >> 
>>> >> <Ahem> “Iterators,” please.
>>> >
>>> > That makes me happy - for some reason I thought it was still GeneratorProtocol
>>> >
>>> >>> destructively, but such Generators would not conform to the needs of
>>> >>> Sequence. As such, the most significant impact would be the inability
>>> >>> to use such Generators in a for..in loop, 
>>> >> 
>>> >> Trying to evaluate this statement, it's clear we're missing lots of
>>> >> detail here:
>>> >> 
>>> >> * Would you remove Sequence?
>>> >> * If so, what Protocol would embody “for...in-able?”
>>> > No, I would just remove the allowance in the documentation and API
>>> > design for a destructive/consuming iteration. Sequence would be the
>>> > interface to getting access to repeatable iteration, without the need
>>> > for meeting the other requirements for Collection.
>>> 
>>> That would be wrong unless there exist substantial examples of a
>>> multipass Sequence that *can't* meet the other requirements of
>>> Collection without loss of efficiency.  And since I can write an adaptor
>>> that turns any multipass sequence into a Collection, I think it's
>>> trivial to prove that no such examples exist.
>>> 
>>> -- 
>>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave