[swift-evolution] [draft] Introduce Sequence.filteredMap(_:)
2th at gmx.de
Wed Oct 25 04:15:57 CDT 2017
>> It’s unfortunate when a piece of code gets a different meaning — but as you said:
>> It’s a misuse, and when you write code that is wrong, the results might be wrong as well.
> And this is exactly that we’re trying to address. Not the impurity of the function, not the performance, but the potential to misuse.
But do you think filterMap can’t be misused? I don’t know why people choose flatMap instead of map, but they might as well just switch to filterMap.
>> Maybe Scala chose better name for the concept, but the Swift definition is consistent as it is now.
> collect does not say anything about the transformation (A => B) that happens along the way…
„collectResults“ is probably clearer… but I guess Scala-folks choose to prefer a single word.
But when it’s about clear naming, we probably should talk about „applyFunctionAndCollectUnwrappedResults“, because filtering has no obvious connection to nil-values.
Even worse, I think filter is the wrong word in this context, because that’s what I’d expect from such a function:
Sequence.filterMap<U>(_: (Element) -> U?) -> [U?]
In this case, the result would only contain those Optionals that contain a value — or there could be a parameter for the filter, defaulted to a check for nil.
>> So, if you remove the third overload, the second one imho should be renamed, too.
> Honestly, I don’t see why. Can you elaborate? The second one is perfectly consistent, it does not mix two different functor instances in the same function.
As it is now, both Sequence and Optional are very similar — they are container types that may be empty.
When you say that one incarnation of flatMap that deals with Optionals is wrong, imho it’s cleaner to break that connection completely, and make it a Collection-only thing.
Overload 2 is kind of a special case of the third one.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution