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

[Tim Vermeulen]

I heard that this has been brought up before, but what if we give all non-mutating methods the same name as their mutating counterparts? The compiler can just pick the right one based on whether an assignment is taking place or not. Here are the advantages I can think of:

- it would end this debate once and for all, because every relevant method name would just be the infinitive
- it makes it way easier to keep the language consistent
- we won’t have to remember which name belongs to the mutating version and which name belongs to the non-mutating version
- people are attached to `map` and `filter`

Last but not least, this could get rid of a lot of boilerplate code. Often, either the mutating or non-mutating version of a method is implemented using the other:

func someNonMutatingMethod() -> Self {
    var copy = self
    copy.someMutatingMethod()
    return copy
}

or:

mutating func someMutatingMethod() {
    self = someNonMutatingMethod()
}

If we only implement one of the two, the compiler could implement the missing method for us (which we then can prevent with the attributes @mutatingOnly and @nonMutatingOnly, or something of the sort). Or we can make this system opt-in instead.

If there are convincing arguments against this, I’d love to hear them.

> Due to considerably support onthis 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
> 
> 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,dropFirstanddropLast. 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)
> 
> 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.filterthey 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.
> 
> 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.
> 
> Detailed design
> 
> The change would rename the following method families:
> 
> map    =>mapped flatMap  =>flatMapped filter  =>filtered reduce  =>reduced dropFirst =>droppingFirst dropLast =>droppingLast
> Impact on existing code
> 
> The Swift migrator and fix-its would be provided for the change.
> 
> Alternatives considered
> Alternatively -ing suffixes could be used formap/flatMap/filter/reduce. However, these are normally reserved for when -ed doesn't really work (e.g. droppedFirst).
> 
> 
> 
> 
> 
>