+1. I doubt anyone would really complain, just had to point it out. > On Dec 30, 2015, at 5:00 PM, Kevin Ballard <[email protected]> wrote: > > 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 >> >> <https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26> >> >>> On Dec 30, 2015, at 4:27 PM, Kevin Ballard <[email protected] >>> <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
