> Am 10.11.2017 um 23:32 schrieb Max Moiseev <mois...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
