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

[Patrick Pijnappel]

Pull-request for the change here: https://github.com/apple/swift/pull/1544

On Sat, Mar 5, 2016 at 1:18 PM, Dmitri Gribenko via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160305/fa19f9cb/attachment.html>