My intuition says the extra state & branch needed for generators like TakeWhile could very well be optimized away in most cases if you dont make use of its post-nil behavior. Say TakeWhile is implemented as such:<div><br></div><div>if done { return nil }</div><div>guard let element = base.next() where predicate(element) else {</div><div> done = true</div><div> return nil</div><div>}</div><div>return element</div><div><br></div><div>If the generator is then used in the common case:</div><div><br></div><div>let generator = TakeWhileGenerator(...)</div><div>while let element = generator.next() {</div> foo(element)<br><div>}</div><div><br></div><div>Should give us effectively:</div><div><br></div><div>var base = ...</div>let predicate = ...<div><div>var done = false</div><div>while true {</div><div> if done { break }</div><div> guard let element = base.next() where predicate(element) else {</div><div> done = true</div><div> break</div><div> }</div><div> foo(element)</div><div>}</div><div><br></div><div>The optimizer should see (or at least could see) `done` is never read after it's written to (thus removing the assignment), and therefore when checking the condition it can only be false (thus it can also be removed).</div><div><br></div><div>I don't have a machine to test this on atm though.</div><div><br><div><div><br>On Sunday, 6 March 2016, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> I think it will be far easier to write generic tests of any generator than it will be to write generic tests of any function that *uses* a generic generator.<br>
>><br>
>> (Although I suppose you could assist in that testing by writing a wrapper around any sequence/collection/generator which enforces all rules as strictly as possible.)<br>
><br>
> You could always just test the behavior of the FuseGenerator wrapping it, if you really want to be able to rely on always-returning-nil behavior. But I'm not sure what tests you'd write that even hits this case, except for a test that's designed specifically to test the post-nil behavior (which we've already established isn't necessary to check for arbitrary generators if GeneratorType leaves that as implementation-defined).<br>
<br>
The fuse generator wouldn't do what I'm talking about. What I mean is that it might be useful for testing purposes to be able to wrap a collection/sequence in a StrictCollection/StrictSequence (with corresponding StrictGenerators, StrictIndexes,etc.) which would do things like:<br>
<br>
* Detect if you copy a generator and then use both copies<br>
* Detect if you call next() on a generator after it returns nil<br>
* StrictCollection only: Invalidate all indices retrieved before any mutation<br>
* StrictSequence only: Prevent you from making a generator more than once<br>
<br>
The idea is that, when you're writing a piece of code that's generic on any collection or sequence type, your unit tests could pass in a StrictCollection/StrictSequence-wrapped version of whatever your actual data is, and if your code doesn't crash you can be pretty sure it's not violating any of those protocols' unevenly enforced requirements.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div></div>