<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2017, at 2:15 AM, Tino <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class="" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">It’s unfortunate when a piece of code gets a different meaning — but as you said:<div class="">It’s a misuse, and when you write code that is wrong, the results might be wrong as well.</div></div></div></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">And this is exactly that we’re trying to address. Not the impurity of the function, not the performance, but the potential to misuse.</span></div></div></div></blockquote><div class="">But do you think filterMap can’t be misused? I don’t know why people choose flatMap instead of map, but they might as well just switch to filterMap.</div></div></div></div></blockquote>Oh I’m sure they will. But I hope it will be harder, because we will have a deprecated overload of a flatMap that will provide a helpful message and guide people to use map instead.<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class="" 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="">Maybe Scala chose better name for the concept, but the Swift definition is consistent as it is now.</div></div></div></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">collect does not say anything about the transformation (A => B) that happens along the way…</span></div></div></div></blockquote><div class="">„collectResults“ is probably clearer… but I guess Scala-folks choose to prefer a single word.</div></div></div></div></blockquote>Let’s not forget about the types. Function type is an essential piece of information that should accompany it’s name. With a function type being (LIst[A], PartialFunction[A, B]) => List[B] the name is almost not needed, there is pretty much one way of implementing this function (if we forget about trivial and wrong implementations that, for example, return an empty list all the time, of perform arbitrary side-effects).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">But when it’s about clear naming, we probably should talk about „applyFunctionAndCollectUnwrappedResults“, because filtering has no obvious connection to nil-values.</div><div class="">Even worse, I think filter is the wrong word in this context, because that’s what I’d expect from such a function:</div><div class=""><pre class="" style="color: rgb(36, 41, 46); box-sizing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; word-wrap: normal; padding: 16px; overflow: auto; line-height: 1.45; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal;"><span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">Sequence</span>.<span class="pl-smi" style="box-sizing: border-box;">filterMap</span><span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);"><</span>U<span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">></span>(<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">_</span>: (<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">Element</span>) <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">-></span> U<span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">?</span>) <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">-></span> [U?]</pre><div class=""><br class=""></div></div><div class="">In this case, the result would only contain those Optionals that contain a value — or there could be a parameter for the filter, defaulted to a check for nil.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="">So, if you remove the third overload, the second one imho should be renamed, too.</div></div></div></blockquote>Honestly, I don’t see why. Can you elaborate? The second one is perfectly consistent, it does not mix two different functor instances in the same function.</div></div></div></blockquote></div>As it is now, both Sequence and Optional are very similar — they are container types that may be empty.<div class="">When you say that one incarnation of flatMap that deals with Optionals is wrong, imho it’s cleaner to break that connection completely, and make it a Collection-only thing.</div><div class="">Overload 2 is kind of a special case of the third one.</div></div></div></blockquote>I was actually thinking in the opposite direction ;-) As in, adding more functions from Collection to Optional. filter can be useful, count, isEmpty, forEach… I’m not saying that it will conform to the Collection protocol, but I can see how sometimes `opt.filter { $0 > 0 }` is a better option than `if let v = opt, x > 0 { … } else { … }</div><br class=""></body></html>