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

[Dave Abrahams]

on Thu Mar 17 2016, Kevin Ballard <swift-evolution at swift.org> wrote:

> On Wed, Mar 16, 2016, at 09:59 AM, Erica Sadun wrote:
>>
>>> On Mar 16, 2016, at 10:41 AM, Joe Groff <jgroff at apple.com> wrote:
>>>
>>>>
>>>> On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>
>>>>
>>>> On Mar 8, 2016, at 7:29 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>
>>>>> One minor change to what I've been proposing: Instead of merely
>>>>> saying that it's implementation-defined, we should expressly say
>>>>> that invoking next() after it has previously returned nil may
>>>>> return nil or it may return an implementation-defined value, but
>>>>> it should not fatalError() (unless some other GeneratorType
>>>>> requirement has been violated). Which is to say, after a
>>>>> GeneratorType has returned nil from next(), it should always be
>>>>> safe to invoke next() again, it's just up to the particular
>>>>> implementation to determine what value I get by doing that.
>>>>>
>>>>> -Kevin Ballard
>>>>
>>>> I'm torn about sequences that end with nil and should continue
>>>> always return nil thereafter and
>>>> (pulling a name out of the air) "samples" that may return nil or non-
>>>> nil values over time. I'd prefer there
>>>> to be two distinct contracts between an iterator and another
>>>> construct that may return an implementation-defined
>>>> value after nil.
>>>
>>> If your sequence produces optional values, then the result of its
>>> generator should be double-optional. If next() returns `.some(nil)`,
>>> that would be a nil value in the sequence; if it returns `nil`,
>>> that's the end.
>>>
>>> -Joe
>>
>> The use case I was thinking of was real-world sampling, where there
>> was actually a value available or not.
>> Using double-optionals as a sequence would work for that. Since that
>> approach might be intuitively
>> obvious, maybe should be clarified through documentation?
>
> Double-optionals makes this pattern useless. The whole point of using
> the Generator pattern here is so you can easily process all of the currently-
> available "samples" and then hit nil and stop, and then later when you
> try again you may or may not get more values. Using a generator that
> returns a double-optional value, the generator would never actually
> return nil directly, it would always return a .Some (either .Some(nil)
> or .Some(value)), and at this point there's no reason to be using a
> Generator at all over just having a method that samples it.

I don't see why you can't just create a new Iterator (neé GeneratorType)
for this purpose.

-- 
Dave