> > 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? On Fri, Jun 17, 2016 at 2:26 PM, Patrick Pijnappel < [email protected]> 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 <[email protected]> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >>> >>> _______________________________________________ >>> 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
