[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Patrick Pijnappel]

>
> -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.

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 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?


On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160617/e8c4fe99/attachment.html>