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

[Vladimir.S]

On 17.06.2016 0:07, Gmail via swift-evolution wrote:
> -0.5
>
> I find the "term of art" argument strong in this case, especially for
> map/filter/reduce.
>
> 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`.

Can you compare 'filter' vs 'sort' ? I.e. it is possible to have in-place 
filter. Just like 'sort'. Why 'sort' is not a term-of-art but "filter" is?

Even more, I'm confused right now, how should I name my own method in type 
that will filter it in-place(i.e. mutating method)?

So, even I think we can leave map/reduce as-is, IMO 'filter' should be 
excluded from this group.

>
> I acknowledge that it’s more consistent, and that - by being a suffix to
> the function name - autocompletion would still result in the
> correct function. However, I don’t find that the extra -ed/-ing suffixes
> provide a lot of extra clarity
>
>
>> On 16 Jun 2016, at 12:51, Patrick Pijnappel via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Due to considerably support on this thread
>> <http://news.gmane.org/find-root.php?group=gmane.comp.lang.swift.evolution&article=20783>,
>> a draft proposal to revisit the core functional method exceptions to the
>> -ed/-ing rule.
>>
>> Online
>> version: https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md
>>
>>
>>   Apply -ed/-ing rule to core functional methods
>>
>>   * Proposal: SE-NNNN
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/NNNN-functional-methods-ed-ing.md>
>>   * Author: Patrick Pijnappel <https://github.com/PatrickPijnappel>
>>   * Status: Awaiting review
>>   * Review manager: TBD
>>
>>
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md#introduction>Introduction
>>
>> The Swift API Guidelines standardizes non-mutating method forms on verbs
>> ending in -ed/-ing (or nouns). However, a few non-mutating forms have
>> been kept as "Terms of
>> Art": |map|, |flatMap|, |filter|, |reduce|, |dropFirst| and |dropLast|.
>> This proposal proposes to bring these in line with all other non-mutating
>> forms (e.g. |filter => filtered|).
>>
>> Swift-evolution threads: Source
>> <http://news.gmane.org/find-root.php?group=gmane.comp.lang.swift.evolution&article=20783>
>>
>>
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md#motivation>Motivation
>>
>> These method have been kept to preserve the terms of art. Generally, this
>> can have significant benefits:
>>
>>   * Anyone familiar with the term will immediately understand it, and use
>>     their assumptions about how it works.
>>   * Users learning the term from Swift can use their knowledge when
>>     encountering it elsewhere.
>>   * Experienced users will be able to use the mental pattern matching
>>     they've built-up for quickly recognizing common programming patterns.
>>
>> However, basically all of the benefits of using a term of art still apply
>> to the modified forms: – For recognition, the modified forms are still
>> very close to the traditional terms of art. So both coming to and from
>> Swift you'll be able to use your knowledge pretty much unaffected.
>>
>>   * If the user looks for e.g. |filter| they are pretty much guaranteed
>>     to quickly find the correct form, be it through code-completion,
>>     google or a fix-it.
>>   * There isn't really any violation of assumptions that might cause
>>     problems in this case.
>>   * Any mental pattern matching will likely transfer quickly due to the
>>     minimal difference.
>>
>>
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md#proposed-solution>Proposed
>>     solution
>>
>> The proposed solution modifies the method verbs to their -ed/-ing forms
>> (preferring the former).
>>
>> It removes the last clear exceptions to the -ed/-ing rule from the
>> standard library, which previously were exactly the opposite of what one
>> would expect based on the API guidelines (and the rest of the language).
>>
>> It also aids users in learning to pattern match on the -ed/-ing rule and
>> internalizing the API guidelines, since now all methods are named this
>> way – instead of the most commonly used methods defying the normal pattern.
>>
>>
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md#detailed-design>Detailed
>>     design
>>
>> The change would rename the following method families:
>>
>> |map => mapped flatMap => flatMapped filter => filtered reduce => reduced
>> dropFirst => droppingFirst dropLast => droppingLast |
>>
>>
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md#impact-on-existing-code>Impact
>>     on existing code
>>
>> The Swift migrator and fix-its would be provided for the change.
>>
>>
>>     <https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/XXXX-functional-methods-ed-ing.md#alternatives-considered>Alternatives
>>     considered
>>
>>   * Alternatively -ing suffixes could be used
>>     for |map|/|flatMap|/|filter|/|reduce|. However, these are normally
>>     reserved for when -ed doesn't really work (e.g. droppedFirst).
>>
>> _______________________________________________
>> 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
>