<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yes, you are right. I was too fast.<div class=""><br class=""></div><div class="">I've been thinking why filterMap has such a traction in the community, despite the fact that this precise "filter" is a tiny subset of the "filter" generally used by the language.</div><div class=""><br class=""></div><div class="">I think "filterMap" clicks well in many readers because of this trend of thought:</div><div class=""><br class=""></div><div class="">1. I need to transform some values and only keep some of them. But I don't want to use `seq.filter { ... }.map { ... }` or `seq.map { ... }.filter { ... }`. I don't even want to think about the ordering of the filter and mapping operations: that's not interesting. I want a versatile filter+map operation that I'll call "filterMap".</div><div class="">2. Now I need a closure that returns a two-state value: either (in+value), or (out).</div><div class="">3. Which existing Swift type fits such a requirement? Optional, of course. The optional itself will stand for the boolean needed by the filtering operation. The wrapped value will give the mapped value. Pretty efficient.</div><div class=""><br class=""></div><div class="">This trend of thought starts from an actual need (I don't know how to call it) and builds a rationale for it to use the words "filter", "map", and the Optional type. It uses optionals as booleans, which is a venial sin. It happens to build a 100% compatible replacement for the old "flatMap".</div><div class=""><br class=""></div><div class="">The "compact" trend of thought introduces a new operation which filter out nils. It happens to build a 100% compatible replacement for the old "flatMap".</div><div class=""><br class=""></div><div class=""><div class="">The previous trend of thought (flatMap) did consider optionals as collections. It happens to confuse people, and has been rejected.</div><div class=""><br class=""></div></div><div class="">The three ways of thinking build the same function. I've been pushing "compact" has a way to better explore the subject. But I really don't know how the Swift community prefers to wire the developer's brains.</div><div class=""><br class=""></div><div class="">Gwendal</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 16 nov. 2017 à 09:12, Anders Ha <<a href="mailto:anders@andersha.com" class="">anders@andersha.com</a>> a écrit :</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="">It does not use `Optional`, but it is semantically equivalent to `filterMap` in CwlSignal and ReactiveSwift, and the `filterMap` proposed for `Sequence` (but in the time domain instead).<div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class="">Regards,</div><div class="">Anders</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 16 Nov 2017, at 2:07 PM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">My opinion is that filterMap is the right choice of name.<br class=""><br class="">I'm completely biased, given that I already have a Swift library that uses filterMap, in exactly this context, for a Reactive Programming library:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3" class="">https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3</a><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Another popular Reactive Programming Library uses filterMap with a different signature, and a different meaning: <a href="https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32" class="">https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32</a></div><div class=""><br class=""></div><div class="">There are already different interpretations on "filter" in "filterMap" in the wild.</div><div class=""><br class=""></div><div class="">Gwendal Roué</div><div class=""><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div></div></blockquote></div><br class=""></div></body></html>