<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 9:52 AM, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I'm trying to work them out, so it's still muddled.</div><div class=""><br class=""></div><div class="">Right now, I think <font face="Menlo" class="">SequenceType</font> is better described as <font face="Menlo" class="">CollectionWalkType</font></div></div></div></blockquote><div><br class=""></div>Why do you say so?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">but that's kind of (1) a mouthful and (2) not entirely accurate.&nbsp;</div><div class=""><br class=""></div><div class="">Moving back a step: <font face="Menlo" class="">SequenceType</font> is defined as: "A type that can be iterated with a `for`...`in` loop." But it says nothing about whether that loop ever terminates and many stdlib sequence functions currently don't make sense (at least if they're not lazy) with respect to infinite sequences, which should probably be "<font face="Menlo" class="">StreamType</font>" not sequences. A couple of examples:</div><div class=""><ul class=""><li class="">Here's my fib:&nbsp;<a href="http://swiftstub.com/189513594/" class="">http://swiftstub.com/189513594/</a></li><li class="">And here's Oisin's user-input sequence: &nbsp;<a href="https://gist.github.com/oisdk/2c7ac33bf2188528842a" class="">https://gist.github.com/oisdk/2c7ac33bf2188528842a</a></li></ul></div><div class="">Both of these are theoretically filterable, but they aren't dropLast-able, suffix-able, properly split-able, etc.</div><div class=""><br class=""></div><div class="">Hopefully that's enough of a starting point to indicate where my thinking is at and what I'm trying to think through when it comes to this. — E</div></div></div></blockquote><div><br class=""></div>All you’ve descrived here is the lack of a distinct protocol for finite sequences, which doesn't indicate “muddled concepts” at all. &nbsp;It's a conscious choice of protocol granularity per&nbsp;<a href="http://news.gmane.org/find-root.php?message_id=2A3E0C76-1C88-4752-8A70-AA64BB14223A@apple.com" class="">this posting</a>&nbsp; &nbsp;In the development of the standard library we’ve tried to keep the API surface area small and given all the factors described in that posting, the conservative choice was to not separate them.</div><div><br class=""></div><div>That’s not to say I’m opposed to carving out a place for finite sequences (and as we approach ABI stability now would be the time to do it) but I’d like to clearly understand why we’re doing it, and ideally I’d like to address all of the concerns noted in the post.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 10:09 AM, Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Dec 31, 2015, at 9:05 AM, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">It does seem that in Swift the concepts of collection, sequence, permutation, stream, etc are a bit muddled.<br class=""></blockquote><br class="">This is a pretty vague critique. &nbsp;Do you have specifics, and suggestions that address them?<br class=""><br class=""><blockquote type="cite" class=""><br class="">-- E<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Dec 31, 2015, at 6:51 AM, Tino Heth via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">Those are collections. &nbsp;Collections can be iterated over multiple times.<br class=""></blockquote>Speaking of the Fibonacci-numbers:<br class="">Sure we can write an algorithm that iterates over them several times — it just won't ever finish the first iteration ;-)<br class="">(only nitpicking — I just couldn't resist)<br class=""><br class="">Happy new year!<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class="">-Dave<br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""><div class="">
-Dave
</div>
<br class=""></body></html>