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

[Max Moiseev]

> On Nov 10, 2017, at 4:07 AM, Tino Heth via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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