[swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard]

On Wed, Dec 30, 2015, at 04:39 PM, Daniel Duan wrote:
> Here it is https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26
>
>> On Dec 30, 2015, at 4:27 PM, Kevin Ballard <kevin at sb.org> wrote:
>>
>> We already don't have a .last on CollectionType and nobody's been
>> complaining about that. Besides, sequences don't necessarily even
>> terminate.
>>
>> -Kevin Ballard
>>
>> On Wed, Dec 30, 2015, at 04:01 PM, Daniel Duan wrote:
>>> Users who don’t get the single-pass nature of SequenceType may
>>> expect a .last as well.

Ah you're right, I was just looking at the unconstrained protocol. In
any case, we could theoretically provide a .last, but I don't think
that's useful enough on sequences to warrant inclusion. I know I've
wanted .first many times and I've never wanted .last.

Another motivation for adding this that I forgot to mention is that
today the code `someCol.lazy.filter(pred).first` actually isn't lazy at
all, it filters the entire collection and builds a new array (because
SequenceType doesn't have .first so it resolves the .filter() to the
eager version instead of the lazy version). Adding .first to
SequenceType makes that expression actually do what the user intended
(although my other proposal for SequenceType.find() provides a much
better way to accomplish the same task).

On Wed, Dec 30, 2015, at 04:40 PM, gs. wrote:
> I like this addition and I think that we should take care to document
> whether or not this mutates the sequence. I actually expect it to but
> maybe I am mistaken.

(moving this back to the list)

I considered documenting that, but none of the existing "destructive"
methods on SequenceType document that. I think the assumption is that
anything that has to inspect the contents of the sequence is obviously
consuming the sequence to do that. In fact, the one method that doesn't
consume anything (not counting generate() since any use of the generator
is destructive), underestimateCount(), is explicitly documented as being
non-destructive.

Also, I couldn't think of a non-awkward way to say "this property
partially consumes the sequence if it's a sequence that is destructively
"consumed" by iteration". Especially because "partially consumed" isn't
actually a property of sequences; it's explicitly documented that
calling generate() a second time after any iteration is allowed to
return a completely arbitrary sequence of elements from the second
generator (for example, a generator that returns lines read from some
stream might buffer more data internally and therefore constructing a
second generator would possibly skip data that was never returned from
the first generator).

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151230/dd63e18d/attachment.html>