> – What sin(x) should do is unambiguous, unlike array.filter { ... }.A decent argument label, like `including` or even `to`, would fix the name `filter`. And as I said, if we feel `filter` is unsalvageable, the alternate Smalltalk-lineage `select` is clearer. > – There's very significant brevity issues here, e.g. hyperbolicArcTangent() > vs atanh(). Sure, but `mappingAndFlattening(to:)` would have brevity issues as well. (You didn't think the API Guidelines merely meant "add -ed or -ing to everything", did you?) > – The relevant metric of the strength of a term of art would be for how many > users it already is a very much ingrained term (i.e. not how long it has been > around). For sin() this is the case for pretty much anyone who has done > high-school math. Conversely, map/filter/reduce will only be significantly > ingrained for experienced users of languages that are functionally-centered > enough to regularly use these, which is a much smaller percentage (though not > insignificant). I think "languages that are functionally-centered enough to regularly use these" makes this set of languages sound rather smaller than it really is. The languages with C in their names—C, C++, Objective-C, and C#—are almost the only ones in modern use which *don't* include higher-order functions. Few people would regard Perl, Javascript, Java, Python, or Ruby as "functional" languages, but all of them support `map`. If you look at RedMonk's list of 21 popular languages <http://fossbytes.com/21-top-programming-languages-on-github-and-stack-overflowjanuary-2016/>: * 1 (CSS) has no real concept of lists or list operations. * 2 (shell and C) do not have closures. * 1 (Go) could support `map`, but K&R still think it's 1973. * 1 (Objective-C) could support `map`, but...well, if the Foundation guys want to tell us why they don't, they know where to find us. * 16 have a version of `map`: * 1 (Matlab) has vectorization features which act like an implicit `map`. * 2 (C# and Visual Basic) have a `select` operation from LINQ * 3 (C++, R, and Groovy) have other names for `map` * 10 (Javascript, Java, PHP, Python, Ruby, Perl, Scala, Go, Haskell, Swift, and Clojure) call it `map`. Of 16 languages with `map`, Scala, Haskell, Clojure, and maybe R and Matlab would typically be considered functional, and all of those are in the bottom half of the list. The other 11 languages with a version of `map` are all mainstream multi-paradigm languages of the sort people coming to Swift might be familiar with. In short: Higher-order functions are not a specialized feature that only the functional eggheads use. Outside of a few small pockets—one of which is native Apple apps—they are a pervasive feature of modern programming environments. They are the rule, not the exception. >> Let me turn your question around: What concrete benefits do we gain from >> modifying terms which are extremely widely recognized? It is not consistent, >> but is there any reason to believe that causes actual confusion? If not, >> then why fix what isn't broken? > > The benefits of renaming: > – It makes learning easier as it establishes a consistent way to read Swift > methods right from the start. > – It would help users in intuitively learning consistent naming for their own > methods, even if they haven't read the API guidelines. These are basically two ways of stating the same point, which again, is not considered strong enough to overcome strong terms-of-art in other areas. > – It allows defining e.g. an in-place filter variant. Several people have mentioned this could be done, but has anyone actually *asked* for it? And if it did exist, wouldn't it be better to offer this functionality as a `remove(where:)` function, matching existing methods like `first(where:)` and `index(where:)`? (Actually, if we're going to rename `filter`, `where` might not be a terrible name. It's valid after a dot, but not without one.) Even if we *do* want to offer it for `filter`, the others are not good candidates for mutating variants. Mutating `map` could only be offered on certain sub-protocols of `Collection`, could not be guaranteed to be in-place (and probably wouldn't be for most collection types), and would have a severely restricted set of use cases compared to its nonmutating equivalent. Mutating `flatMap` would suffer even more from these limitations, making it desperately tricky to implement. And `reduce` simply couldn't be offered at all. > I agree with your points on the problems with dropFirst/dropLast btw. Incidentally, I just noticed that `removeFirst(_:)`/`removeLast(_:)` ought to get this treatment too. I'll see if I can write up at least a sketch of what I'd like to do to these methods in the next few days, but I'm busy today preparing for the local (Orange County, CA) Apple community's post-WWDC event. Need to come up with something to talk about. :^) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
