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