<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=""><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="" 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>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><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>„collectResults“ is probably clearer… but I guess Scala-folks choose to prefer a single word.</div><div>But when it’s about clear naming, we probably should talk about „applyFunctionAndCollectUnwrappedResults“, because filtering has no obvious connection to nil-values.</div><div>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><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>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></body></html>