[swift-evolution] [SR-933] Rename flatten to flattened
Dave Abrahams
dabrahams at apple.com
Sun Apr 10 12:33:00 CDT 2016
on Fri Apr 08 2016, Brent Royal-Gordon <swift-evolution at swift.org> wrote:
>> The 'flatten()' method didn't get the Swift 3 API renaming treatment
>> it should have, to go along with reversed, sorted, joined, etc.
>> As I see Dmitri Gribenko already agree with it but we still have to
>> discuss it here. So what do you think?
>
> I'm in favor.
>
> Though all of these things are terms of art, not all terms of art are created equal. For instance:
>
> * `map` is supported by virtually any language which have any of these
> higher-order functions, and to my knowledge the name `map` is
> universally used.
> * `reduce` is not quite as universally supported, but it's still very
> common, and most (but not quite all) languages with higher-order
> functions support it.
> * `filter` is very widely supported, but the *name* `filter` is not
> quite so consistent. Ruby, for instance, calls it `select`, Perl calls
> it `grep`, etc.
> * `takeWhile` lies on the other end of the spectrum, being very narrowly supported.
>
> In my opinion, it would be a really bad idea to rename `map` or
> `reduce`; `filter` is probably a bad idea but not terrible; but we
> should feel relatively free to rename `takeWhile`.
>
> `flatten` is nowhere near as weak a term of art as `takeWhile`, but I
> think it still falls towards that end of the spectrum. We shouldn't
> worry too much about changing it. `map`, `reduce`, and `filter` are
> much stronger terms, and we should be more cautious about changing
> them.
The problem is flatMap. The semantics of map, flatMap, and flatten are
inextricably linked. IMO it would be weird to do this to one or two of
these names and not to all of them.
--
Dave
More information about the swift-evolution
mailing list