<div dir="ltr"><div>+1</div><div><br></div><div>• What is your evaluation of the proposal?</div><div><br></div><div><div>I am highly in favor of this proposal. I have seen so many of my peers struggle with custom types, like Result and Observable, that implement a functional flatMap as opposed to the aforementioned flatMap that I've seen create a barrier of learning. While my observation is anecdotal, it speaks to an existing, greater churn to a journey of understanding as opposed to a provisional swift migration.</div></div><div><br></div><div>• Is the problem being addressed significant enough to warrant a change to Swift?</div><div><br></div><div>Yes.</div><div><br></div><div>• Does this proposal fit well with the feel and direction of Swift?</div><div><br></div><div>Yes.</div><div><br></div><div>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div><div><br></div><div>This change will properly align the definition of flatMap across other languages.</div><div><br></div><div>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div><br></div><div>A quick reading.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 6:18 PM, Paul Cantrell via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div style="word-wrap:break-word;line-break:after-white-space"><br></div><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><blockquote type="cite">On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></blockquote></span><div><span class=""><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-5205593849004220384Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space">On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><div><blockquote type="cite"><br class="m_-5205593849004220384Apple-interchange-newline"><div>
<div><div>On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:<br></div>
<blockquote type="cite"><div style="word-wrap:break-word;line-break:after-white-space"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-stretch:normal;line-height:normal;background-color:rgb(255,255,255)"><div>The problem in the Doodads example is that <b>the name <span class="m_-5205593849004220384colour" style="color:rgb(88,126,168)"><span class="m_-5205593849004220384font" style="font-family:Menlo"><span class="m_-5205593849004220384size" style="font-size:11px">flatMap</span></span></span> is used to identify two distinct intents</b>: concatenating arrays and filtering nils. One can argue that those two operations are, in some lofty abstract sense, if you squint, two instances of some more general pattern — but I don’t think it’s fair to say that they represent the same <i>intent</i>. These separate intents deserve separate names.<br></div>
</div>
</div>
</div>
</blockquote><div><br></div>
<div>They absolutely represent the same intent if you think of an optional as a collection of zero or one elements.</div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>This is precisely the “lofty abstract sense, if you squint” to which I was referring. I stand by that characterization. Just because there is a clever isomorphism between two types doesn’t mean people use them with equivalent intent.</div><div><br></div><div>Splitting that hair aside, the point of that example code stands: using the same name for both flatMap variants causes the type checker to miss programmer errors it would otherwise catch. (And unlike the first motivating example in the proposal, the “warn on optional hoisting” feature would not help at all.)</div><span class=""><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div>
</div></div></blockquote></div><div>But as `Optional` does not conform to collection, I would suggest that the vast majority of of developers do _not_ think of them as a collection of zero or one elements. (I certainly don’t know any who naturally think of it that way.) We don’t treat Optional as a collection anywhere else in the API, and it seems odd to do so in just this one case.</div></div></div></div></blockquote><div><br></div><div>And, to be clear, the lack of Collection conformance by Optional is an active choice, not an omission.</div><div><br></div><div>The “think of optionals as collections” explanation is a good way to help people who are confused by the overload. But an even better way would be to not have a confusing overload in the first place.</div></div></div></div></blockquote></span></div><br><div>Exactly so. A much crisper way of stating my sprawling argument.</div><div><br></div><div>I’m personally grateful that Swift reminds me that, for example, I need the question mark in <span style="font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">view.</span><span style="color:rgb(88,126,168);font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">gestureRecognizers</span><span style="font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">?.</span><span style="color:rgb(88,126,168);font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">co<wbr>unt</span>. It would be maddening if <span style="font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">view.</span><span style="color:rgb(88,126,168);font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">gestureRecognizers</span><span style="font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">.</span><span style="color:rgb(88,126,168);font-family:Menlo;font-size:11px;background-color:rgb(255,255,255)">cou<wbr>nt</span> compiled, and always returned either 0 or 1. Imagine it!</div><div><br></div><div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(88,126,168);background-color:rgb(255,255,255)"><span style="color:#000000"> view.</span>gestureRecognizers<span style="color:#000000">.</span>coun<wbr>t<span style="color:#000000"> </span><span style="color:#668b49">// returns 0</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(88,126,168);background-color:rgb(255,255,255)"><span style="color:#000000"> view.</span>gestureRecognizers<span style="color:#000000"> = []</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(88,126,168);background-color:rgb(255,255,255)"><span style="color:#000000"> view.</span>gestureRecognizers<span style="color:#000000">.</span>count<span style="color:#000000"> </span><span style="color:#668b49">// now returns 1 (wat?)</span></div></div><div><div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(88,126,168);background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)"> view.</span>gestureRecognizers<span style="color:rgb(0,0,0)"> = [foo, bar, baz]</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(88,126,168);background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)"> view.</span>gestureRecognizers<span style="color:rgb(0,0,0)">.</span>coun<wbr>t<span style="color:rgb(0,0,0)"> </span><span style="color:rgb(102,139,73)">// still returns 1</span><span style="color:rgb(102,139,73)"> </span><span style="color:rgb(102,139,73)">(wat?!)</span></div></div></div><div><span style="color:rgb(102,139,73)"><br></span></div><div>That is a recipe for torches and pitchforks right there. Yet it is analogous to what flatMap currently does.</div><div><br></div><div>Cheers,</div><div><br></div><div>Paul</div><div><br></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>