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

[Erica Sadun]

> On Mar 16, 2016, at 12:05 PM, Joe Groff <jgroff at apple.com> 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?
> 
> The sequence itself would have a singly-optional element type—it's only next() that adds optionality on top of that. For most use cases, next() is just an implementation detail.
> 
> -Joe

I meant, in the stdlib docs for GeneratorType / public mutating func next() -> Self.Element?

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160316/19bfc187/attachment.html>