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