I submitted another proposal a few hours ago regarding @available(*, unavailable) that's designed to turn this into a compile-time error.
Although I wonder if a stopgap would be to provide a `first` property on LazySequenceType that's marked as unavailable. I haven't checked to see how that behaves but I hope it would trigger an error instead of resolving to the eager filter. -Kevin Ballard On Dec 31, 2015, 12:40 AM -0800, Dave Abrahams<[email protected]>, wrote: > > -Dave > > On Dec 30, 2015, at 5:00 PM, Kevin Ballard via > > swift-evolution<[email protected](mailto:[email protected])>wrote: > > On Wed, Dec 30, 2015, at 04:39 PM, Daniel Duan wrote: > > > Here it > > > ishttps://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). > > Oh, that’s nasty.I wonder if there’s something we can do with ambiguity to > make the eager overload inaccessible in that context?Would you mind opening a > bug for this? > > > 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](mailto:[email protected]) > > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
