On Wed, Mar 16, 2016, at 09:59 AM, Erica Sadun wrote: > >> On Mar 16, 2016, at 10:41 AM, Joe Groff <[email protected]> wrote: >> >>> >>> On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution >>> <[email protected]> wrote: >>> >>> On Mar 8, 2016, at 7:29 PM, Kevin Ballard via swift-evolution >>> <[email protected]> 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. -Kevin Ballard
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
