[swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

[Jordan Rose]

> On Mar 8, 2016, at 11:38, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Sun, Mar 6, 2016 at 6:16 PM, Kevin Ballard via swift-evolution
> <swift-evolution at swift.org> wrote:
>> On Sun, Mar 6, 2016, at 05:46 AM, Patrick Pijnappel wrote:
>> 
>> 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:
>> 
>> if done { return nil }
>> guard let element = base.next() where predicate(element) else {
>>  done = true
>>  return nil
>> }
>> return element
>> 
>> If the generator is then used in the common case:
>> 
>> let generator = TakeWhileGenerator(...)
>> while let element = generator.next() {
>>  foo(element)
>> }
>> 
>> Should give us effectively:
>> 
>> var base = ...
>> let predicate = ...
>> var done = false
>> while true {
>>  if done { break }
>>  guard let element = base.next() where predicate(element) else {
>>    done = true
>>    break
>>  }
>>  foo(element)
>> }
>> 
>> 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).
>> 
>> 
>> This may be doable for stdlib generators, but Swift currently has a
>> limitation where generic types/functions defined outside the current file
>> (or module with -whole-module-optimization) are only specialized for their
>> parameters if they come from the stdlib. Any such types/functions defined in
>> third-party libraries (or in other files if you're not using
>> -whole-module-optimization) use virtual dispatch on the generic parameters
>> instead. This means that any generic GeneratorTypes defined in third-party
>> libraries won't be able to optimize away this check as it won't be able to
>> tell that it isn't needed.
> 
> This is a current limitation of the compiler.  The resilience effort
> should make the specialization available for user-defined modules.
> Thus, I don't think it makes sense to factor in the current limitation
> into a long-term decision.

That's not really true; in fact I'd say it's the opposite. Any library that's not shipped with the app has the freedom to change its generator implementation in the future, and therefore you'll get even fewer guarantees about the generator than you have today.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160308/74345db8/attachment.html>