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

[Paul Cantrell]

> On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto: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

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