What I meant by flagging the renaming of the generic `flatMap` to the more specific-to-this-case `filterMap` is that all of the current uses of `flatMap` share conceptual details: they all process whatever is in the box, then perform one level of flattening.
This shared concept is hugely valuable, IMO, for people who are new to Swift in being able to form an understanding of what these functions do, and also for library authors who are creating box types and want discoverable, intuitive API names. This is the reason why I lean towards keeping `flatMap` and adding a compiler warning for incorrect/redundant uses. Cheers, Sam On Fri, 10 Nov 2017 at 05:43 BJ Homer <bjho...@gmail.com> wrote: > > On Nov 9, 2017, at 11:35 AM, Tino Heth <2...@gmx.de> wrote: > > > This proposal only proposes renaming the “filterNonesAndMap” variant > (though that name is misleading, it would be “filterNonesAfterMapping” if > anything); the other uses of flatMap will remain unchanged. > > … then it should be really right: As I learned in the thread, there is a > map step before filter, and another map afterwards - so > „filterNonesAfterMappingAndMap“ (that’s why I don’t like the use of the > term „filter“ here — if you want an accurate name that contains this verb, > it gets quite complicated…) > > > But obviously “filterNonesAfterMappingAndMap” is not a name we’re going to > end up with. You can argue that “filterMap” is not completely faithful to > the internal implementation, but I think it’s clearly better than “flatMap” > in this case, which is even *more* incorrect. I’m not opposed to finding > a better name than “filterMap”, but so far I haven’t seen one. > > -BJ >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
