> > You could make the exact same arguments about `sin`.
– What sin(x) should do is unambiguous, unlike array.filter { ... }. – There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh(). – 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). 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. – It allows defining e.g. an in-place filter variant. I agree with your points on the problems with dropFirst/dropLast btw. On Fri, Jun 17, 2016 at 4:05 PM, Vladimir.S <sva...@gmail.com> wrote: > On 17.06.2016 15:58, Patrick Pijnappel wrote: > >> I suggest to leave map+flatMap+reduce as-is as true terms-of-art >> >> >> Question still stands, what benefits do we gain from using the /exact/ >> terms that are not present in the slightly modified ones? >> > > I don't know :-) I just see that many against renaming of > map/filter/reduce/etc and suggest a compromise : we leave map/reduce as-is, > but nothing else should be an exception to the naming rules. > > >> On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel >> <patrickpijnap...@gmail.com <mailto:patrickpijnap...@gmail.com>> wrote: >> >> `map`, `filter`, and `reduce` are *the* higher-order functions. >> Almost anything with any kind of block/lambda/closure feature >> supports them (I'm giving the side-eye to Foundation here), and >> all >> three names are backed by *very* strong conventions >> >> >> >> If `map`, `filter`, and `reduce` are not covered by the >> term-of-art >> rule, we might as well rename it to the sin()-and-Int rule, >> because >> I don't know what else it would cover. There is remarkable >> consistency in the naming of these operations across dozens of >> languages. >> >> >> The point the proposal raises is that the modified versions preserve >> the the terms of art in all the senses that matter (i.e. all the >> benefits like recognition etc. still apply). >> >> On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <sva...@gmail.com >> <mailto:sva...@gmail.com>> wrote: >> >> On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote: >> >> -1, for the same reasons stated on the thread. These are >> neither >> guaranteed to be mutating or non-mutating until you get to >> Collection. >> Changing map() to mapped() would be lying to the developer >> some of the >> time about the mutability of the interface. >> -DW >> >> >> Actually the -ed/-ing suffix is *not *intended to guarantee >> non-mutatability. It merely communicates whether it is a >> "return-a-transformed-version-of-the-instance"-type method as >> opposed to an >> in-place mutation. Clearly these are not in-place forms. Note >> that this is >> my interpretation of the intent of the guidelines (or what >> should be the >> intent) – if the core team agrees perhaps this deserves >> clarification in >> the document. >> >> >> Totally agree with you. I also understand this rule as separation >> of "in-place"/"returns transformed version". I.e. the suffix >> should >> say just "result of this operation will be returned and should be >> assigned to other instance variable". Otherwise, as I understand, >> ANY method that will touch or iterate the Sequence *could* mutate >> it and so potentially we should have no -ing/-ed methods for >> Sequence - no? >> >> >> These functions are different than for example `sort` >> because there >> can’t be a general mutating method of `map`. A variable of >> type `[A]` >> can’t be mutated to hold a `[B]` which would be the result >> of a map >> from `A -> B`. >> >> >> There could definitely be an in-place variant of filter. While >> a /fully/ >> general method would not be possible for the others, an user >> might >> reasonable expect in-place variants of map/flatMap if T == U >> as >> with e.g. { >> $0 * 2 } or Optionals, and of dropFirst/dropLast if >> SubSequence >> == Sequence >> as with e.g. String. >> >> Also note that the -ed/-ing rule should not be merely for >> ambiguous cases, >> it should tell the user that the main use of the method is >> returning a >> transformed version of the instance. Having this be a rule you >> can depend >> on is important. >> >> >> +1 >> >> >> -1 The Term of Art argument is very strong with these >> functions. I >> prefer them as-is. >> >> >> What specific benefits do we obtain from using the /exact >> /terms of art vs. >> the very slightly modified versions proposed? >> >> >> Although I believe we can leave map&reduce as-is, I can understand >> if we'll change them to mapped/reduced and will have consistent >> naming everywhere, don't think this will cause any confusion for >> one who will start to use them. In any case, we can add a hint in >> compiler like "did you mean 'mapped'?". >> >> >> >> On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via >> swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org >> >> <mailto:swift-evolution@swift.org>>> wrote: >> >> > The 'reduce()' at its core take an array of element and >> reduce it to single element (could be of a different type) as >> such it cannot ever be mutating (if one really want it, one >> could reduce an array to the same array but it is not the goal >> of the function). For this one it sound to me nearly like >> asking to rename 'max()' to 'maxed()', 'count' to 'counted' or >> implement a 'summed()' instead of a 'sum()' for [Int]. >> >> `max`, `count`, and `sum` are all nouns—at least in the >> senses they are >> meant in those calls—so they do not take the -ed/-ing >> suffixes to form >> immutable variants. Instead, they would take the `form` >> prefix to form >> mutable variants, if they had them. >> >> `map`, `filter`, and `reduce`—at least in the senses they >> must be >> interpreted in for the names of those calls to make >> sense—are verbs, >> and so they *would* normally take -ed/-ing suffixes. >> However, as >> broadly-accepted terms of art, we have left them alone >> until now. >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> <mailto:swift-evolution@swift.org> >> <mailto:swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution