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

[Mark Sands]

+1

• What is your evaluation of the proposal?

I am highly in favor of this proposal. I have seen so many of my peers
struggle with custom types, like Result and Observable, that implement a
functional flatMap as opposed to the aforementioned flatMap that I've seen
create a barrier of learning. While my observation is anecdotal, it speaks
to an existing, greater churn to a journey of understanding as opposed to a
provisional swift migration.

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

Yes.

• 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?

This change will properly align the definition of flatMap across other
languages.

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

A quick reading.

On Thu, Nov 9, 2017 at 6:18 PM, Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:
>
> The problem in the Doodads example is that *the name flatMap is used to
> identify two distinct intents*: concatenating arrays and filtering nils.
> One can argue that those two operations are, in some lofty abstract sense,
> if you squint, two instances of some more general pattern — but I don’t
> think it’s fair to say that they represent the same *intent*. These
> separate intents deserve separate names.
>
>
> They absolutely represent the same intent if you think of an optional as a
> collection of zero or one elements.
>
>
> This is precisely the “lofty abstract sense, if you squint” to which I was
> referring. I stand by that characterization. Just because there is a clever
> isomorphism between two types doesn’t mean people use them with equivalent
> intent.
>
> Splitting that hair aside, the point of that example code stands: using
> the same name for both flatMap variants causes the type checker to miss
> programmer errors it would otherwise catch. (And unlike the first
> motivating example in the proposal, the “warn on optional hoisting” feature
> would not help at all.)
>
> But as `Optional` does not conform to collection, I would suggest that the
> vast majority of of developers do _not_ think of them as a collection of
> zero or one elements. (I certainly don’t know any who naturally think of it
> that way.) We don’t treat Optional as a collection anywhere else in the
> API, and it seems odd to do so in just this one case.
>
>
> And, to be clear, the lack of Collection conformance by Optional is an
> active choice, not an omission.
>
> 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.
>
>
> Exactly so. A much crisper way of stating my sprawling argument.
>
> I’m personally grateful that Swift reminds me that, for example, I need
> the question mark in view.gestureRecognizers?.count. It would be
> maddening if view.gestureRecognizers.count compiled, and always returned
> either 0 or 1. Imagine it!
>
>     view.gestureRecognizers.count  // returns 0
>     view.gestureRecognizers = []
>     view.gestureRecognizers.count  // now returns 1 (wat?)
>     view.gestureRecognizers = [foo, bar, baz]
>     view.gestureRecognizers.count  // still returns 1 (wat?!)
>
> That is a recipe for torches and pitchforks right there. Yet it is
> analogous to what flatMap currently does.
>
> Cheers,
>
> Paul
>
>
> _______________________________________________
> 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/20171109/01b30862/attachment.html>