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

Dmitri Gribenko gribozavr at gmail.com
Fri Mar 4 20:18:20 CST 2016

On Fri, Mar 4, 2016 at 5:51 PM, Dave Abrahams via swift-evolution
<swift-evolution at swift.org> wrote:
> on Fri Mar 04 2016, Patrick Pijnappel <swift-evolution at swift.org> wrote:
>>> What algorithms or components can be simplified by taking advantage of this
>>> extra guarantee?
>> Any generator that somehow buffers their underlying generator (as it can't
>> tell whether it already tried to refill the buffer). For example UTF8 &
>> UTF16's decode() both have 3 instead of 2 branches on ASCII input because
>> of this.
>>> Off the top of my head: a stream of random numbers that stops when it
>>> encounters
>>> a zero.
>> You could generate the next random number in advance (you take a O(1) hit
>> instead of O(n)). Of course consuming more than you need is not always
>> allowed and the O(1) could outweigh the branch.
>> Overall I'd say performance-wise both categories are small (though taking
>> the standard library as sample case, we have some examples of the former
>> but not the latter).
>> We'd be left with the safety concern of code which fails in rare corner
>> cases.
> Thanks, this is helpful.  I'm leaning in favor of making the change.

After thinking about this more, in context of implementation
experience, existing generators in the library, I'm also in favor of
providing this guarantee.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list