<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 3:36 PM, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" class="">cacoyi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Related to this I've been toying around with a tweak to GeneratorType - it could clear up some of the issues with <font face="monospace, monospace" class="">.first</font> consuming part of the sequence:<div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="color:rgb(187,44,162)" class="">public</span> <span style="color:rgb(187,44,162)" class="">protocol</span> NewGeneratorType {</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">typealias</span> Element</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">func</span> next() -> (value: <span style="color:rgb(112,61,170)" class="">Element</span>, state: <span style="color:rgb(112,61,170)" class="">Self</span>)?</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">}</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><br class=""></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><span style="color:rgb(187,44,162)" class="">extension</span><span style="" class=""> </span>NewGeneratorType<span style="" class=""> {</span></div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">mutating</span> <span style="color:rgb(187,44,162)" class="">func</span> next() -> <span style="color:rgb(112,61,170)" class="">Element</span>? {</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">let</span> nextPair: (value: <span style="color:rgb(112,61,170)" class="">Element</span>, state: <span style="color:rgb(112,61,170)" class="">Self</span>)? = <span style="color:rgb(187,44,162)" class="">self</span>.<span style="color:rgb(49,89,93)" class="">next</span>()</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">if</span> <span style="color:rgb(187,44,162)" class="">let</span> state = nextPair?.state {</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">self</span> = state</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> }</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color:rgb(187,44,162)" class="">return</span> nextPair?.value</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> }</div></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">}</div></div></blockquote><div class=""><br class=""></div>I haven't had time for a proposal yet, but thought I'd mention it as it seemed relevant.</div></div></blockquote><div><br class=""></div><div>The only way this can solve the problem is that if your new next() method is required to return the same result for multiple consecutive calls. There’s a reason GeneratorType wasn’t designed that way: it effectively requires generators of volatile streams to have a 1-element buffer, which is an avoidable overhead for the many algorithms make a single pass and don’t try to get the same element multiple times (consecutively). Any algorithm that wants to do that can keep its own cache instead of imposing the cache overhead on every generator.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 31, 2015 at 7:40 PM, Dave Abrahams via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class="">
<div class="">-Dave</div>
</div>
<br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 30, 2015, at 5:00 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class="">
<div class=""><div class="">On Wed, Dec 30, 2015, at 04:39 PM, Daniel Duan wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">Here it is <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26" target="_blank" class="">https://github.com/apple/swift/blob/master/stdlib/public/core/CollectionAlgorithms.swift.gyb#L26</a><br class=""></div>
<div class=""><div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">On Dec 30, 2015, at 4:27 PM, Kevin Ballard <<a href="mailto:kevin@sb.org" target="_blank" class="">kevin@sb.org</a>> wrote:<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><div class="">We already don't have a .last on CollectionType and nobody's been complaining about that. Besides, sequences don't necessarily even terminate.<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""> </div>
<div class="">On Wed, Dec 30, 2015, at 04:01 PM, Daniel Duan wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">Users who don’t get the single-pass nature of SequenceType may expect a .last as well.<br class=""></div>
</blockquote></div>
</div>
</blockquote></div>
</div>
</blockquote><div class=""> </div>
<div class="">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.<br class=""></div>
<div class=""> </div>
<div class="">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). </div></div></div></blockquote><div class=""><br class=""></div></span>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? </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""><div class=""><div class="">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).<br class=""></div>
<div class=""> </div>
<div class="">On Wed, Dec 30, 2015, at 04:40 PM, gs. wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">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.<br class=""></div>
</blockquote><div class=""> </div>
<div class="">(moving this back to the list)<br class=""></div>
<div class=""> </div>
<div class="">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.<br class=""></div>
<div class=""> </div>
<div class="">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).<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=JfMPa-2F7wwZPzsZ3QKA8NjtONIYX4SjbWuUxtpfsTY2hr20Kkib8Yd2rLIiLiiElKYMDUuUCXNdm3m9qHodoQ97gEmjN185HJjqjKRGARBxFOSGC5DG-2FWevhfWHltUcA0-2BJ9kON-2FmGD2KNjIOQrKOAJleIaIjTG-2FMYcGrmSHQWffPdtF13u7cvY0gkQBIO0g60eCjCYa-2BaqtY-2Bzd7Cp3OyU-2BghouDXrXAS5easlISNeQ-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div></span><span class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uRq1QASyV7ackd-2F2fyNxFupk-2FU0I1IjzVxjPK-2Ff6GxFr0Q4C3wojkm6MxG-2BJtWsSVwDko8eahkwPgbqZmnAimqJR6z8kMIV9qpi98UrOVKannhODWD-2FeWaeGBXrSU2yrMEWx9lUUeicJlQkgoP-2FdhU3Dhg74QdmVf8dLKxGzmQrkGwLxdzkD1apSeBzCO4aQCE-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important" class="">
</div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""><div class="">
-Dave
</div>
<br class=""></body></html>