> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
