<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Point taken, in theory it is possible that someone’s program would change unexpectedly if we change the function’s signature. But wouldn’t you agree that this was a very contrived example? I can’t think of a lot more than converting it to a string that works on both optionals and non-optionals.</div><div class=""><br class=""></div><div class="">`sequence(first:next:)` has only been available in Swift 3 beta versions, which are known to change over time. Shouldn’t we be focused on getting the function signature just right before Swift 3 is released?</div><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Aug 2016, at 02:41, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 15, 2016 at 7:23 PM, Tim Vermeulen<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:tvermeulen@me.com" target="_blank" class="">tvermeulen@me.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On 16 Aug 2016, at 02:11, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:tvermeulen@me.com" target="_blank" class="">tvermeulen@me.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><div class=""><div style="direction: inherit;" class="">If I'm not mistaken, the type of T can be inferred from the `next` closure here. $0 is an optional, so you end up with a sequence of optionals.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Currently, yes. But if we have both </div><div class=""><br class=""></div><div class=""><div class="">public func sequence<T>(first: T, next: @escaping (T) -> T?) -> UnfoldFirstSequence<T> { ... }</div><div class="">public func sequence<T>(first: T?, next: @escaping (T) -> T?) -> UnfoldFirstSequence<T> { ... }</div></div><div class=""><br class=""></div><div class="">then $0 could be inferred to be of type `T` or `T?`, right?</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I was indeed talking about replacing the first function by the second, not having them side by side.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">And if we replace the first function with the second (instead of having both), then the same code that gives you an UnfoldFirstSequence<T?> today would give you an UnfoldFirstSequence<T> tomorrow, which would be the most pernicious way to break code (subtle, hard to catch unless you know what you're looking for, with a potentially massive difference in behavior).</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I’m not sure I follow. First of all, I think an unfold sequence with an optional element is pretty far-fetched, but fair enough, they may exist. But why would the type suddenly change? Type inference would still figure out the right type, no? An example would be greatly appreciated, because I don’t see how this could form a problem.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">```</div><div class="">// This function is silly,</div><div class="">// but useful functions may take a similar form</div><div class="">func foo(_ x: Int?) -> Int? {</div><div class=""> guard let x = x else { return 0 }</div><div class=""> return x > 12 ? nil : x + 1</div><div class="">}</div><div class=""><br class=""></div><div class="">let a: Int? = nil</div><div class="">for i in sequence(first: a, next: { foo($0) }) {</div><div class=""> // This is a pretty useless thing to do,</div><div class=""> // but there are useful things that can be done</div><div class=""> // without checking whether `i == nil`</div><div class=""> print(i)</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">If you change the function signature, the number of lines printed by this example code will change from 14 to 0.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><div class=""><div class=""><div class="">On 16 Aug 2016, at 00:51, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Given:<br class=""><br class="">let foo: T? = something()<br class="">let bar = sequence(first: foo, next: { $0?.frobnicate() })<br class=""><br class="">If first could be of type `T` or `T?`, is bar of type `UnfoldSequence<T>` or `UnfoldSequence<T?>`?<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Aug 15, 2016 at 17:15 Tim Vermeulen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">I doubt that’s it, in no way is an an empty sequence inherently unsafe. The entire standard library is built with empty sequences in mind. I’m more inclined to think it’s an oversight.</div></div><div style="word-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 15 Aug 2016, at 23:15, Maximilian Hünenberger <<a href="mailto:m.huenenberger@me.com" target="_blank" class="">m.huenenberger@me.com</a>> wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class=""></div><div class="">Ok, I see. However this could be a potential source of bugs/performance issues where you don't consider the nil case and you do some unnecessary work. By prohibiting to pass nil you have to manually unwrap and you immediately see the "optionality".</div><div class=""><br class="">Am 15.08.2016 um 22:36 schrieb Tim Vermeulen <<a href="mailto:tvermeulen@me.com" target="_blank" class="">tvermeulen@me.com</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Oh, that’s true, I misunderstood your previous message. It’s not about passing nil, but it’s about passing optionals. The point is to be able to do something like this:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="color: rgb(186, 45, 162);" class="">let</span><span class=""><span class="Apple-converted-space"> </span>number = functionThatReturnsAnOptional(<wbr class="">)</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span class="">sequence(first:<span class="Apple-converted-space"> </span></span><span style="color: rgb(79, 129, 135);" class="">number</span><span class="">, next: { $0 %<span class="Apple-converted-space"> </span></span><span style="color: rgb(39, 42, 216);" class="">2</span><span class=""><span class="Apple-converted-space"> </span>==<span class="Apple-converted-space"> </span></span><span style="color: rgb(39, 42, 216);" class="">0</span><span class=""><span class="Apple-converted-space"> </span>? $0 /<span class="Apple-converted-space"> </span></span><span style="color: rgb(39, 42, 216);" class="">2</span><span class=""><span class="Apple-converted-space"> </span>:<span class="Apple-converted-space"> </span></span><span style="color: rgb(186, 45, 162);" class="">nil</span><span class=""><span class="Apple-converted-space"> </span>})</span></div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 15 Aug 2016, at 22:26, Maximilian Hünenberger <<a href="mailto:m.huenenberger@me.com" target="_blank" class="">m.huenenberger@me.com</a>> wrote:</div><br class=""><div class=""><div class="">Probably I didn't understand your proposal. What do you want to change exactly?<br class=""><br class="">I thought:<br class="">public func sequence<T>(first: T, next: @escaping (T) -> T?) -> UnfoldFirstSequence<T> { ... }<br class=""><br class="">To:<br class="">public func sequence<T>(first: T?, next: @escaping (T) -> T?) -> UnfoldFirstSequence<T> { ... }<br class=""><br class=""><blockquote type="cite" class="">Am 15.08.2016 um 22:17 schrieb Tim Vermeulen <<a href="mailto:tvermeulen@me.com" target="_blank" class="">tvermeulen@me.com</a>>:<br class=""><br class="">You can’t; the `first` parameter has type `T`, not `T?`.<br class=""><br class=""><blockquote type="cite" class="">On 15 Aug 2016, at 22:10, Maximilian Hünenberger <<a href="mailto:m.huenenberger@me.com" target="_blank" class="">m.huenenberger@me.com</a>> wrote:<br class=""><br class="">Hi Tim,<br class=""><br class="">If you pass "nil" to "first" isn't this an empty sequence? So it would be redundant.<br class=""><br class="">Best regards<br class="">Maximilian<br class=""><br class=""><blockquote type="cite" class="">Am 15.08.2016 um 01:27 schrieb Tim Vermeulen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>:<br class=""><br class="">sequence(first:next:) takes a non-optional first argument. Is there a reason for that? sequence(state:next:) allows empty sequences, and I don’t see why sequence(first:next:) shouldn’t. The fix would be to simply add the `?` in the function signature; no other changes are required to make it work.<br class=""><br class="">I considered just filing a bug report, but since this is a change of the public API...<br class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></blockquote></blockquote><br class=""></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div>______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>