<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 Jan 5, 2016, at 16:43 , Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div class="">On Tue, Jan 5, 2016, at 03:43 PM, Jordan Rose wrote:<br class=""></div>
<blockquote type="cite" class=""><div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">On Jan 2, 2016, at 23:53, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""> </div>
<div class=""><blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" type="cite" class=""><div class=""> </div>
<div class="">On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""> </div>
<div class="">On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote:<br class=""></div>
<blockquote type="cite" class=""><blockquote type="cite" class="">`buffered` is no more problematic than `lazy` is. In fact, calling `buffered` actually doesn't have any side-effects at all (it can avoid fetching the first element until you call `first` on the result of `buffered`).<br class=""></blockquote><div class=""> </div>
<div class="">If `seq` is a single-pass sequence, then `seq.buffered.first` will consume an element from `seq`, even though you only accessed two properties. That's why I call it problematic.<br class=""></div>
<div class=""> </div>
<div class="">(If calling `buffered` somehow rendered the original sequence unusable—for instance, if we had some way to express that the `BufferedSequence` takes unique ownership of its base—this wouldn't bother me as much.)<br class=""></div>
</blockquote><div class=""> </div>
<div class="">If `sequence` is a single-pass sequence, wrapping it in any other sequence type and then doing anything with that other sequence type makes the original sequence unusable (or rather, you can still use it but the elements yielded from any further access to the original sequence can be completely arbitrary).<br class=""></div>
<div class=""> </div>
<div class="">And for the record we already have precedent for the specific case of `seq.prop1.prop2` destructively consuming the original sequence: `seq.lazy.array`.<br class=""></div>
</blockquote><div class=""> </div>
<div class=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">Yes, and there are arguments for dropping “.array” as a property. The convention is that “conversions” (ill-defined, I know) use constructor syntax, and we are currently heading towards the elimination of "convenience” interfaces that duplicate functionality, so we might end up with Array(seq). </span></span><br class=""></div>
<div class=""> </div>
<div class=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">All that said, single-pass Sequences are just weird in that they get mutated without calling any mutating methods on them; you mutate them by calling a mutating method on a separate generator instance. In other words, they fundamentally have reference semantics. There may be some better way to address this whole area, but we’ll have to go much deeper than merely poking at the question of a `.first` property.<span class=""></span></span></span><br class=""></div>
</div>
</blockquote></div>
<div class=""> </div>
<div class="">Should "generate()" be a mutating method on SequenceType, then? And a non-mutating one on CollectionType, obviously.<br class=""></div>
</blockquote><div class=""> </div>
<div class="">No, that would make SequenceType too hard to use. Specific sequences could still have non-mutating generate() methods, but any kind of generic Sequence wrapper would be forced to use a mutating generate(), and that would make the ergonomics of using them awful. For example, instead of<br class=""></div>
<div class=""> </div>
<div class=""> for x in seq.lazy.map(f) { ... }<br class=""></div>
<div class=""> </div>
<div class="">you'd have to say<br class=""></div>
<div class=""> </div>
<div class=""> var seq2 = seq.lazy.map(f)<br class=""></div>
<div class=""> for x in seq { ... }<br class=""></div>
<div class=""> </div>
<div class="">And in the end, it wouldn't really solve anything anyway, because you can still implement single-pass sequences using a non-mutating generate() anyway (either the sequence is a class, or it uses a class or UnsafeMutablePointer internally, or it manipulates global state, e.g. a sequence that reads lines from stdin with readLine()).<br class=""></div>
<div class=""> </div></div></div></blockquote><br class=""></div><div>That's a good point. I still feel like there's something missing (see also my Sequence/Generator/Collection thoughts on the PermutationGenerator thread), but we certainly wouldn't want to break simple, common uses of LazySequence or AnySequence.</div><div><br class=""></div><div>Thanks for steering me in the right direction.</div><div>Jordan</div><br class=""></body></html>