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

[Patrick Pijnappel]

>
>  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 <
patrickpijnappel at 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 <svabox at 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 at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/dc52b0b6/attachment.html>