> On Mar 16, 2016, at 12:05 PM, Joe Groff <[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? > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
