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