> Question still stands, what benefits do we gain from using the exact terms > that are not present in the slightly modified ones?
Instant, unambiguous recognition. Look. You could make the exact same arguments about `sin`. We could create a `sine()` method on FloatingPoint and install a dummy `sin(_:)` function with a `renamed` attribute pointing to it. Why don't we do that? Because it's not the terminology used for that domain. There is a universal convention, stretching back hundreds of years, for how you write "get the sine of this number", and `n.sine()` is not that convention, so we don't use it. Similarly, there is a nearly universal convention, stretching back to Lisp's `maplist` function in 1959 (!!!), pointing at the term `map`. `reduce` dates back to APL in 1962, although of course that was the term used in the documentation, since APL relied so heavily on operators. These terms are steeped in history as rich as anything in programming. By sticking to the exact terms, there is no question that yes, this is the same function programmers have been using since the Eisenhower administration. By contrast, changing the name would seem to hint that it *isn't* the standard `map` function. Maybe Swift, like Java, calls its dictionaries `Map`s, and `mapped` or `mapping` is an operation to convert an array into a `Map`. And even if it's not confusing, it's going to confound the muscle memory of programmers who use both Swift and another language with higher-order list functions. 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? That's why I want to focus on the first/last/prefix/suffix methods. There I see real problems: misleading names, tangled and unclear relationships, and little reason to tolerate the situation to preserve terms of art. Renaming `map`, `reduce`, and `filter`, by contrast, seem to be mostly about consistency for the sake of consistency, not consistency for the sake of concrete benefits. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
