<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Wed, Mar 16, 2016, at 09:59 AM, Erica Sadun wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Mar 16, 2016, at 10:41 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br></div>
<div> </div>
<div><blockquote 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;" type="cite"><div> </div>
<div>On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div> </div>
<div>On Mar 8, 2016, at 7:29 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<blockquote type="cite"><div> </div>
<div>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></div>
<div> </div>
<div>-Kevin Ballard<br></div>
</blockquote><div> </div>
<div>I'm torn about sequences that end with nil and should continue always return nil thereafter and<span> </span><br></div>
<div>(pulling a name out of the air) "samples" that may return nil or non-nil values over time. I'd prefer there<br></div>
<div>to be two distinct contracts between an iterator and another construct that may return an implementation-defined<br></div>
<div>value after nil.<br></div>
</blockquote><div> </div>
<div><span class="font" style="font-family:Palatino-Roman"><span class="size" style="font-size:14px">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></span><br></div>
<div> </div>
<div><span class="font" style="font-family:Palatino-Roman"><span class="size" style="font-size:14px">-Joe</span></span><br></div>
</div>
</blockquote></div>
<div> </div>
<div>The use case I was thinking of was real-world sampling, where there was actually a value available or not. <br></div>
<div>Using double-optionals as a sequence would work for that. Since that approach might be intuitively<br></div>
<div>obvious, maybe should be clarified through documentation?<br></div>
</blockquote><div> </div>
<div>Double-optionals makes this pattern useless. The whole point of using the Generator pattern here is so you can easily process all of the currently-available "samples" and then hit nil and stop, and then later when you try again you may or may not get more values. Using a generator that returns a double-optional value, the generator would never actually return nil directly, it would always return a .Some (either .Some(nil) or .Some(value)), and at this point there's no reason to be using a Generator at all over just having a method that samples it.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
</body>
</html>