> On 8 Nov 2017, at 7:23 AM, John McCall via swift-evolution 
> <[email protected]> wrote:
> 
> Hello, Swift community!
> 
> The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs 
> through November 14th, 2017.  The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>  
> <https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md>
> 
>       • What is your evaluation of the proposal?

It is a welcomed change provided that it does help with future integrity of the 
affected APIs.

But I am not sure that the solution is the best fit. It bends over the API 
while apparently the crux is the implicit optional promotion. Shouldn’t we 
consider the feasibility of disabling the promotion for this specific overload 
before proceeding with renaming? This wasn’t addressed in the proposal.

>       • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. I agree that the unintended hole caused by future collection conformances 
and optional implicit promotion should be mitigated.

But in principle, I don’t see a problem with all of them being called 
`flatMap`, since `Optional` is effectively a 0- or 1-element collection, just 
without the `Collection` conformance.

>       • Does this proposal fit well with the feel and direction of Swift?

Yes.

>       • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

ReactiveSwift calls this operation `filterMap` too (but operating on a reactive 
stream instead). As far as I could recall, we picked this name since (1) the 
operation is effectively map-then-filter; (2) it is named the same by Erlang, 
Elm, Rust, etc; and (3) we see no point to pull in new verbs to convey the 
meaning.

Some have expressed concerns about `filterMap` being the reverse of the actual 
operation (i.e. map-then-filter). While I have no exact idea of why `flatMap` 
was picked instead of `mapFlatten` by the early FP communities, my perception 
of the reasoning is that `mapFlatten(transform)` would be perceived as 
`mapFlattened` at first glance due to the LTR writing order.

>       • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading since these APIs are often used daily.

> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> <https://github.com/apple/swift-evolution/blob/master/process.md>
> 
> As always, thank you for contributing to the evolution of Swift.
> 
> John McCall
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution


_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to