I agree with this and add that the 2.2 naming is unambiguous. There’s no doubt what is meant by sortInPlace().
> On Apr 14, 2016, at 9:26 AM, David Rönnqvist via swift-evolution > <[email protected]> wrote: > > I don’t particularly like these name changes. > > I would even go as far as saying that these recent discussions about renaming > flatten, map, filter, reduce has made me question the original Swift 3 API > renaming. What I mostly like about the current (2.2) naming is that the > non-mutating version is the default (for example `sort`/`sortInPlace` > compared to `sorted`/`sort`). I feel that switching the default version to be > the mutating variant is quite a strong statement on the languages behalf with > regards to mutability vs immutability. > > - David > >> on Sun Apr 10 2016, Arsen Gasparyan<to.arsen.gasparyan-AT-gmail.com>wrote: >> >>> Ok. Is it final decision? >> No, any API change needs to go through review on the evolution list. >> Also, FWIW, I am not particularly keen on changing these names. >> >>> Can I start working on it? >>> >>> On Sun, 10 Apr 2016 at 23:07, Howard Lovatt via swift-evolution >>> <[email protected]>wrote: >>> >>> Do it to them all: flatMapped, unioned, etc. >>> >>> On Monday, 11 April 2016, Dave Abrahams via swift-evolution >>> <[email protected]>wrote: >>> >>> on Fri Apr 08 2016, Brent Royal-Gordon<[email protected]> >>> 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 >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> -- >>> -- Howard. >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> -- >> Dave >> >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
