<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 24, 2017, at 5:10 AM, Tino &lt;<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>&gt; 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="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;">Calling "flatMap" a map + filtering out the nil values was a TERRIBLE idea.</div></div></blockquote></div>maybe I’m the one who’s getting this all wrong, but afaik the purpose of flatMap isn’t filtering out nil at all, but just a combination of map &amp; flatten…<div class="">Optional&lt;T&gt; is like Array&lt;T&gt; with a maximal capacity of one (so it can either contain a single object, or it’s empty), and in this interpretation, there’s nothing wrong with the behavior.</div></div></div></blockquote></div><div><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=""></div><div class="">Instead, I think Nobuo Saito is right, and that a renaming to filteredMap is only fighting symptoms, and not the cause (but I’m not that sure if there’s a good way to tackle the cause).</div><div class="">Besides that, all those alternative names also have potential for confusion:</div><div class="">Imho it isn’t intuitive what is filtered out — and don’t forget that the result of flatMap can contain nil elements…</div><div class=""><br class=""></div><div class="">If the biggest problem of flatMap is that people who don’t understand it write code that isn’t optimal (but still does the right thing!), I don’t think there is any change needed. I’m not even sure that that wrapping/unwrapping is actually done, because it should be discoverable by the compiler.</div></div></div></blockquote>It can be seen that the generated SIL is more complicated for a flatMap case, the microbenchmark also shows that it’s about 3x slower than the map. But even if that can be optimized away, don’t you find a String example from the proposal even a little convincing?<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=""></div><div class="">It would be nice if there was an way to warn in places where flatMap could be replaced with map, though (but imho this special warning shouldn’t be checked by the compiler).</div></div></div></blockquote>I tried to avoid renaming:&nbsp;<a href="https://github.com/apple/swift/pull/7823/" class="">https://github.com/apple/swift/pull/7823/</a>&nbsp;but then&nbsp;<a href="https://github.com/apple/swift/pull/9390" class="">https://github.com/apple/swift/pull/9390</a>.<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=""></div><div class="">- Tino</div></div></div></blockquote></div><br class=""></body></html>