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. Otherwise, I'm agreed that there should not be a precondition or fatal error (unless another requirement was violated.) -- Erica _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
