<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 10:41 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">On Mar 8, 2016, at 7:29 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">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.<br class=""><br class="">-Kevin Ballard<br class=""></blockquote><br class="">I'm torn about sequences that end with nil and should continue always return nil thereafter and<span class="Apple-converted-space"> </span><br class="">(pulling a name out of the air) "samples" that may return nil or non-nil values over time. I'd prefer there<br class="">to be two distinct contracts between an iterator and another construct that may return an implementation-defined<br class="">value after nil.<br class=""></blockquote><br style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">-Joe</span></div></blockquote></div><br class=""><div class="">The use case I was thinking of was real-world sampling, where there was actually a value available or not. </div><div class="">Using double-optionals as a sequence would work for that. Since that approach might be intuitively</div><div class="">obvious, maybe should be clarified through documentation?</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></body></html>