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