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

(Jon Hull) #1


I was definitely surprised when these weren't changed with the other methods. They will still be easily found with the new names, and the current inconsistency makes the -ed/-ing rule much harder to grok / trust (especially considering how often these are used).

I do understand David Waite’s objections, but I think that issue needs to be solved separately, as it is also a problem for things like ‘sorted’. It basically affects all “non-mutating” methods on Sequence, and we should come up with a fix for that situation as a whole (in a separate proposal).



Due to considerably support on this thread
<http://news.gmane.org/find-root.php?group=gmane.comp.lang.swift.evolution&article=20783 <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:

Apply -ed/-ing rule to core functional methods

   - Proposal: SE-NNNN
   - Author: Patrick Pijnappel <https://github.com/PatrickPijnappel>
   - Status: Awaiting review
   - Review manager: TBD


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 <http://news.gmane.org/find-root.php?group=gmane.comp.lang.swift.evolution&article=20783>>

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


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.

The change would rename the following method families:

map => mapped
flatMap => flatMapped
filter => filtered
reduce => reduced
dropFirst => droppingFirst
dropLast => droppingLast

on existing code

The Swift migrator and fix-its would be provided for the change.

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