[swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Tino Heth]

> Am 10.11.2017 um 23:32 schrieb Max Moiseev <moiseev at apple.com>:
> 
>> extension Collection {
>> 	func filterMap<T>(transform: (Element) -> T, include: (T) -> Bool) -> [T] {
>> 		return self.map(transform).filter(include)
>> 	}
>> }
> 
> I understand the risk of diverging the discussion, but still, what’s the benefit of having this function over using the built-in `.lazy.map{}.filter{}` ?

I didn’t want to write any additional posts in this thread ;-), but as you ask a concrete question:
Imho there isn't any benefit over just using the two methods — it might be different for special cases with default values for one of the parameters (like getting rid of NaN, Zero or Infinity in a collection of floats), but I wouldn’t expect any of those to be part of the stdlib.
It’s just that this function is the natural interpretation of its name (especially for someone who knows flatMap), and I encountered people who are convinced that flatMap on Collections of Optionals is just like that: You map, you filter, you return the result (some even thought it’s the other way round, filtering being the first step).
Please note that the actual implementation of the method doesn’t matter at all for me — what matters is expectation (after all, I wouldn’t rename flatMap to joinMap), and the expectation for a filter is quite clear.

What kept the dispute alive that long is not that much that I think filterMap is a bad name per se, it is the widespread belief that it is a better description than flatMap.
Me and others strongly disagree here, and I’m quite sure no argument can change my mind on that. Therefor, the whole basis of the discussion is flawed, and I would be quite disappointed if the rationale for the acceptance of this proposal would be that flatMap is a wrong name, and filterMap is correct.
The real question should be if the renaming is beneficial for developers — and in this regard, wrong beliefs can work as good a good as true ones: As many people seem to have the same misconception about flatMap, it might be better to accept that (although I would like to see Kevin Ballards idea implemented anyways).

Concatenation is such a case: It doesn’t follow the laws of addition at all, but still, the same operator that is well established for adding numbers was chosen for it, because of the popular believe that joining two collections is like adding two numbers.

Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171111/cc5fdb0f/attachment.html>