<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=""><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="">I prefer to think of it this way: it does a mapping, and keeps the results where the closure did not return nil. In the example given earlier, the closure returned Optional<Int?>.some(nil), which is not “nil”.</span><br 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;" class=""></div></blockquote></div>Exactly; therefore, flatMap can even „create“ nil values…<div class="">Filters in the physical world aren’t perfect either, and the spam problem has the same issues in the digital domain — but compared with that, eliminating nil is quite simple.</div><div class="">So people (not all, but imho many) will think that filterMap works like an idealized filter, where you pour dirty water in, and get a crystal clear and consumable result.</div><div class=""><br class=""></div><div class="">How would you rate a filter that adds dirt to its product, or a high-pass that adds a significant component below the cutoff frequency to a signal?</div><div class=""><br class=""></div><div class="">Filters aren’t supposed to do that, even if you feed them something strange like Optional<Optional<T>>… and when it adds something that wasn’t in the input, it might be a catalysator, but not a filter (the filter-method in Swift follows that rule as well: It can only map [T?] to [T?], not [T]).</div><div class=""><br class=""></div><div class="">So I have no doubt that flatMap is a better description of what is happening („you map, unwrap the results, and put them all in the same container“ — that’s true for collections as well as for optionals), but if many people have problems with it, something should be changed...</div><div class="">It wouldn’t be the first time where a problematic syntax is added because it pleases the user (whenever I write something like „array0 + array1“, the mathematician in me cries), but in this case, there is no need to choose something that veils what it is doing:</div><div class="">There are alternatives that don’t have this issue („collect“, „collectResults“...), but I actually would prefer just adding a warning to the problematic form of flatMap — simply because without that, nothing will stop people from misusing filterMap in the same way as they do with flatMap now.</div></body></html>