on Thu Mar 17 2016, Kevin Ballard <swift-evolution@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 <jgr...@apple.com> wrote: >>> >>>> >>>> On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org> wrote: > >>>> >>>> On Mar 8, 2016, at 7:29 PM, Kevin Ballard via swift-evolution >>>> <swift-evolution@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution