> On Nov 10, 2017, at 4:07 AM, Tino Heth via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> The “think of optionals as collections” explanation is a good way to help
>> people who are confused by the overload. But an even better way would be to
>> not have a confusing overload in the first place.
> With the renaming, confusion might strike less often, but with bigger impact
> (free translation of a real discussion):
> A: Cool, filterMap makes much more sense than flatMap!
> Me: Why do you thing so?
> A: Well, it does a mapping, and then applies a filter to get rid of nils, and
> that's super useful!
> Me: I see. So you can be sure that when you apply the filterMap method, the
> result doesn’t contain any nil values?
> A: Don’t you understand the concept of a filter? Of course, that’s what I
> just said, you never have to worry about nil!
>
> [me shows a very simple proof that this is completely wrong]
>
> Even here on the mailing lists, people seem to have a wrong understanding of
> what flatMap actually does, and this is reinforced with the renaming.
> It might have no considerable effect on real-world code, because even with
> false assumptions, correct results are possible — but I really would prefer
> to leave the name filterMap free for something like this:
>
> 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{}` ?
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
