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

Patrick_Pijnappel · June 16, 2016, 7:51pm

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:

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](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`, `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), [Draft](http://news.gmane.org/find-root.php?group=gmane.comp.lang.swift.evolution&article=20864)

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

This file has been truncated. show original

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

<swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub;
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>
<swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub;
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.

<swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub
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.
<swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub
design

The change would rename the following method families:

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

<swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub
on existing code

The Swift migrator and fix-its would be provided for the change.
<swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub
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).

David_Ronnqvist · June 16, 2016, 9:07pm

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

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Brent_Royal-Gordon · June 16, 2016, 10:21pm

map => mapped
flatMap => flatMapped
filter => filtered
reduce => reduced

You posted before I finished responding to this on the other thread, so I guess I'll do it here.

You're right that renaming these operations wouldn't be terrible. But I think they're easily distinguishable from things like `dropFirst`, and distinguishable in a way that tilts rather strongly towards leaving these as-is.

`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:

* `map` is by far the strongest. It is universally supported among languages with higher-order collection operations, and is almost always called `map`. In Wikipedia's list of 32 languages with a `map` <https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison>, we find (grouping together similar names like `map` and `maplist`, and double-counting languages with several aliases):

  Map: 19
  Collect: 3
  Apply: 3
  Special syntax: 2
  Select: 1 (C#, which uses it in the SQL-inspired LINQ)
  Transform: 1 (C++, which uses a bizarre signature involving an out parameter)
  ForEach: 1 (XPath)

* `filter` is supported nearly as widely as `map`, and the name `filter` is used nearly as consistently as `map`. Wikipedia lists 27 languages supporting a `filter`-style function, and `filter` is by far the most common choice, arguably favored even more consistently than `map` <https://en.wikipedia.org/wiki/Filter_(higher-order_function)>:

  Filter: 17
  Select: 4
  Special syntax: 3
  FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a closure)
  Where: 1 (C#, in LINQ)
  CopyIf: 1 (C++, bizarre signature)
  FindAll: 1
  Grep: 1
  RemoveIfNot: 1

* `reduce` is extremely popular among functional languages because it's a primitive list-handling operation, although it's a little less common among mainstream languages than the other two. It *does* actually have an alternate name, `fold`, which is nearly as common as `reduce`. However, languages using `fold` are usually those which support both leftward- and rightward-reducing versions of the operation, whereas languages using `reduce` usually don't. Swift falls into the second camp. From Wikipedia's 39-language list <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>:

  Reduce: 20 (with both left and right: 4)
  Fold: 18 (with both left and right: 12)
  Inject: 3
  Special syntax: 3
  Aggregate: 1 (C#, in LINQ)
  Accumulate: 1 (C++, bizarre signature)
  Partition: 1
  ToIterator: 1

(Note that, although I *would* have counted the -ed or -ing forms of these names with the originals, I don't believe I saw any.)

Another illustration of the strength of these names: Google named a distributed computing project MapReduce, and everyone basically understood what it meant.

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.

(Incidentally, I think if we *do* decide to rename the main higher-order list APIs, they would be better named as `mapping(to:)`, `flatMapping(to:)`, `filtering(by:)`, and `reducing(from:with:)`. Unlike `sorted`, the parameters are mandatory and deeply necessary to understand what the call does, so they deserve grammatical labels. Grammatical labels usually imply -ing form, not -ed form. If we want to address Dave's complaint about the ambiguity of `filter`, we might rename that to `selecting(where:)`, which is crystal clear about whether it keeps the true elements or the false ones.)

dropFirst => droppingFirst
dropLast => droppingLast

Here, however, I think you're being under-ambitious.

* Even with a nonmutating suffix, `dropping` carries such a strong connotation of deletion that I think it's a poor choice. I would prefer `skipping`, which is much more clearly an operation that doesn't change anything (and finds precedent in other languages—`skip*` functions are a common alternative name for `drop*` functions.)

* The `First` and `Last` suffixes are inappropriate for the versions of this function which take an argument. These are inverse operations to `prefix(_:)` and `suffix(_:)`, and should be named accordingly.

* `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` are sort of strange, because they're tied deeply into indices and aren't closely related to the other prefix/suffix methods. I would at least seriously consider renaming these to `upTo(_:)`, `through(_:)`, and `from(_:)`—or perhaps even reimagine these entirely as subscripts `[upTo:]`, `[through:]`, and `[from:]`.

This is the area where the term-of-art argument is weaker, the API is more inconsistent and difficult to understand, and the methods are more rarely seen and so more important to be understandable without remembering them. All of these factors combine to make the gains from rationalizing them greater.

`map`, `flatMap`, `filter`, and `reduce` are in some ways the "sexy" targets: We use them all over the place, and changing them would "fix" more lines of code. But these calls are so common, and so heavily precedented, that few users will be confused by them—they've probably seen them before Swift, and even if they haven't, they'll see them enough to keep their meanings fresh in their minds. It is the dimmer, less loved corners of the standard library which we ought to focus on, because they stand to benefit much more from following the conventions than the things we use constantly.

···

--
Brent Royal-Gordon
Architechies

hartbit · June 16, 2016, 11:09pm

-1 The Term of Art argument is very strong with these functions. I prefer them as-is.

···

On 16 Jun 2016, at 12:51, Patrick Pijnappel via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Brent_Royal-Gordon · June 17, 2016, 1:24am

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

Dany_St-Amant · June 17, 2016, 1:04am

Isn't the rule only for the case where you can have a mutating and non-mutating variant?

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

Dany

···

Le 16 juin 2016 à 15:51, Patrick Pijnappel via swift-evolution <swift-evolution@swift.org> a écrit :

Due to considerably support on this thread, 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
Author: Patrick Pijnappel
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, 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

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.
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 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

DevAndArtist · June 16, 2016, 7:53pm

+1 very much for consistency.

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution (swift-evolution@swift.org) schrieb:

Due to considerably support on this thread, a draft proposal to revisit the core functional method exceptions to the -ed/-ing rule.

Online version: swift-evolution/XXXX-functional-methods-ed-ing.md at functional-methods-ed-ing · PatrickPijnappel/swift-evolution · GitHub

Apply -ed/-ing rule to core functional methods

Proposal: SE-NNNN
Author: Patrick Pijnappel
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, 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

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.
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 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

johankj · June 16, 2016, 10:07pm

-1 for the aforementioned reasons by David Waite and T.J. Usiyan.

···

On Thu, Jun 16, 2016 at 9:51 PM, Patrick Pijnappel via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Patrick_Pijnappel · June 17, 2016, 5:02am

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · June 17, 2016, 12:22pm

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

···

On 17.06.2016 0:07, Gmail via swift-evolution wrote:

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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · June 17, 2016, 12:32pm

+1 for naming consistency. Opposite to many other modern languages where these methods/funcs exists, Swift choose another way(inverted) to name func/methods - "normal" name for mutating methods and with -ing/-ed suffix for non-mutating.

But as a compromise, I suggest to leave map+flatMap+reduce as-is as true terms-of-art, and exclude all other names from this group of exceptions. To have strong and clear naming rules you can rely on. Opinions? Probably this could be a solution to this naming issue.

···

On 16.06.2016 22:51, Patrick Pijnappel via swift-evolution 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Patrick_Smith · June 17, 2016, 11:30am

map => mapped
flatMap => flatMapped
filter => filtered
reduce => reduced

You posted before I finished responding to this on the other thread, so I guess I'll do it here.

You're right that renaming these operations wouldn't be terrible. But I think they're easily distinguishable from things like `dropFirst`, and distinguishable in a way that tilts rather strongly towards leaving these as-is.

`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:

* `map` is by far the strongest. It is universally supported among languages with higher-order collection operations, and is almost always called `map`. In Wikipedia's list of 32 languages with a `map` <https://en.wikipedia.org/wiki/Map_(higher-order_function)#Language_comparison>, we find (grouping together similar names like `map` and `maplist`, and double-counting languages with several aliases):

  Map: 19
  Collect: 3
  Apply: 3
  Special syntax: 2
  Select: 1 (C#, which uses it in the SQL-inspired LINQ)
  Transform: 1 (C++, which uses a bizarre signature involving an out parameter)
  ForEach: 1 (XPath)

* `filter` is supported nearly as widely as `map`, and the name `filter` is used nearly as consistently as `map`. Wikipedia lists 27 languages supporting a `filter`-style function, and `filter` is by far the most common choice, arguably favored even more consistently than `map` <https://en.wikipedia.org/wiki/Filter_(higher-order_function)>:

  Filter: 17
  Select: 4
  Special syntax: 3
  FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a closure)
  Where: 1 (C#, in LINQ)
  CopyIf: 1 (C++, bizarre signature)
  FindAll: 1
  Grep: 1
  RemoveIfNot: 1

* `reduce` is extremely popular among functional languages because it's a primitive list-handling operation, although it's a little less common among mainstream languages than the other two. It *does* actually have an alternate name, `fold`, which is nearly as common as `reduce`. However, languages using `fold` are usually those which support both leftward- and rightward-reducing versions of the operation, whereas languages using `reduce` usually don't. Swift falls into the second camp. From Wikipedia's 39-language list <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>:

  Reduce: 20 (with both left and right: 4)
  Fold: 18 (with both left and right: 12)
  Inject: 3
  Special syntax: 3
  Aggregate: 1 (C#, in LINQ)
  Accumulate: 1 (C++, bizarre signature)
  Partition: 1
  ToIterator: 1

(Note that, although I *would* have counted the -ed or -ing forms of these names with the originals, I don't believe I saw any.)

Great research. Thanks for doing this.

Another illustration of the strength of these names: Google named a distributed computing project MapReduce, and everyone basically understood what it meant.

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.

(Incidentally, I think if we *do* decide to rename the main higher-order list APIs, they would be better named as `mapping(to:)`, `flatMapping(to:)`, `filtering(by:)`, and `reducing(from:with:)`. Unlike `sorted`, the parameters are mandatory and deeply necessary to understand what the call does, so they deserve grammatical labels. Grammatical labels usually imply -ing form, not -ed form. If we want to address Dave's complaint about the ambiguity of `filter`, we might rename that to `selecting(where:)`, which is crystal clear about whether it keeps the true elements or the false ones.)

It would seem strange in one way to get rid of such strong terms of art (and also since they are nice and short, they are easy to glance at), but it also seems very inconsistent to keep them. These are methods that will be used by new programmers to Swift, so is it better to keep the existing terms or to modify them?

Say my type has a method filtered(with: Author), is it then strange that I am changing tense within the method’s implementation?

filtered(with author: Author) -> [Item] {
return items.filter{ $0.author == author }
}

Would it not make more sense to write?

filtered(with author: Author) -> [Item] {
return items.filtered(where: { $0.author == author })
}

dropFirst => droppingFirst
dropLast => droppingLast

Here, however, I think you're being under-ambitious.

* Even with a nonmutating suffix, `dropping` carries such a strong connotation of deletion that I think it's a poor choice. I would prefer `skipping`, which is much more clearly an operation that doesn't change anything (and finds precedent in other languages—`skip*` functions are a common alternative name for `drop*` functions.)

+1 to skipping

* The `First` and `Last` suffixes are inappropriate for the versions of this function which take an argument. These are inverse operations to `prefix(_:)` and `suffix(_:)`, and should be named accordingly.

* `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` are sort of strange, because they're tied deeply into indices and aren't closely related to the other prefix/suffix methods. I would at least seriously consider renaming these to `upTo(_:)`, `through(_:)`, and `from(_:)`—or perhaps even reimagine these entirely as subscripts `[upTo:]`, `[through:]`, and `[from:]`.

I really like the subscript idea. Named subscripts are not used nearly enough as they could. This gives these similar index-related operations a common home, and I believe would work well with autocomplete after typing a `[`.

I could even imagine a `[filtering:]` / `[where:]` / `[passing:]` instead of `filtered()`, but can imagine it might be unpopular.

This is the area where the term-of-art argument is weaker, the API is more inconsistent and difficult to understand, and the methods are more rarely seen and so more important to be understandable without remembering them. All of these factors combine to make the gains from rationalizing them greater.

`map`, `flatMap`, `filter`, and `reduce` are in some ways the "sexy" targets: We use them all over the place, and changing them would "fix" more lines of code. But these calls are so common, and so heavily precedented, that few users will be confused by them—they've probably seen them before Swift, and even if they haven't, they'll see them enough to keep their meanings fresh in their minds. It is the dimmer, less loved corners of the standard library which we ought to focus on, because they stand to benefit much more from following the conventions than the things we use constantly.

`filter` is the big one to me, as it is a common verb that people are likely to use in their own `filtered-` methods. `reduce` is also a common verb, so it does make sense to change to `reducing`, however I don’t imagine many people will be writing their own `reducing-` methods, and similarly `mapping-`, so these possibly fall more into the terms of art category for me; `filtered` is the most important one. Besides, the word 'map' always suggests to me that a new array/sequence will be returned, and never replace each item by mutation.

`filtered`: +1
`reducing`: +0.7
`mapping`: + 0.2

···

On 17 Jun 2016, at 8:21 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

timv · June 18, 2016, 1:02am

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

griotspeak · June 16, 2016, 8:40pm

no

-1

I agree that the names of these methods are inconsistent in the abstract
but they are established terms of art, in my opinion.

···

On Thu, Jun 16, 2016 at 1:38 PM, David Waite via swift-evolution < swift-evolution@swift.org> 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

On Jun 16, 2016, at 1:53 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

+1 very much for consistency.

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution (
swift-evolution@swift.org) schrieb:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

griotspeak · June 16, 2016, 8:49pm

Thinking on it more after that–admittedly–visceral reaction, the proposed
changes would be an annoying break from the terms but would remain as
discoverable via autocomplete and can still be found easily when searching.
I'd like to amend my vote to 0. If it makes the methods/functions easier to
read for others, go for it.

···

On Thu, Jun 16, 2016 at 1:40 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

no

-1

I agree that the names of these methods are inconsistent in the abstract
but they are established terms of art, in my opinion.

On Thu, Jun 16, 2016 at 1:38 PM, David Waite via swift-evolution < > swift-evolution@swift.org> 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

On Jun 16, 2016, at 1:53 PM, Adrian Zubarev via swift-evolution < >> swift-evolution@swift.org> wrote:

+1 very much for consistency.

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution (
swift-evolution@swift.org) schrieb:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dwaite · June 16, 2016, 8:38pm

-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

···

On Jun 16, 2016, at 1:53 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

+1 very much for consistency.

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

dabrahams · June 17, 2016, 9:33pm

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

In the same way that leaving it as "map" is lying to the developer, the
other part of the time.

···

on Thu Jun 16 2016, David Waite <swift-evolution@swift.org> wrote:

-DW

On Jun 16, 2016, at 1:53 PM, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org> wrote:

+1 very much for consistency.

--
Adrian Zubarev
Sent with Airmail

Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution
(swift-evolution@swift.org
<mailto:swift-evolution@swift.org>)
schrieb:

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
<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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

VladimirS · June 17, 2016, 11:59am

Support Patrick's opinion. It seems for me that 'map'(+'flatMap') and 'reduce' could be leaved as-is as *true* terms of art. Nothing else should be added to these exception group.

Also please consider this code:
let foo = elements .map {..} .reduce() {...} .filter {} .sorted {}
why is so: "filter" but "sorted"

Note, that if *non-mutating* versions of methods were chosen to have "normal" names in Swift(as was before 3.0) - we'll have no questions regarding "map"/"reduce"/"filter"/"sort"/etc IMO the reason we have this questions now is *other* modern languages has non-mutating methods with "normal" names.

So, as soon as Swift decided to move its own way, IMO it should take only these 2(3) methods as "term of art" and change all other method names to conform to Swift's own naming rules.

···

On 17.06.2016 14:30, Patrick Smith via swift-evolution wrote:

On 17 Jun 2016, at 8:21 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

map => mapped
flatMap => flatMapped
filter => filtered
reduce => reduced

You posted before I finished responding to this on the other thread, so I guess I'll do it here.

You're right that renaming these operations wouldn't be terrible. But I think they're easily distinguishable from things like `dropFirst`, and distinguishable in a way that tilts rather strongly towards leaving these as-is.

`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:

* `map` is by far the strongest. It is universally supported among languages with higher-order collection operations, and is almost always called `map`. In Wikipedia's list of 32 languages with a `map` <Map (higher-order function) - Wikipedia, we find (grouping together similar names like `map` and `maplist`, and double-counting languages with several aliases):

  Map: 19
  Collect: 3
  Apply: 3
  Special syntax: 2
  Select: 1 (C#, which uses it in the SQL-inspired LINQ)
  Transform: 1 (C++, which uses a bizarre signature involving an out parameter)
  ForEach: 1 (XPath)

* `filter` is supported nearly as widely as `map`, and the name `filter` is used nearly as consistently as `map`. Wikipedia lists 27 languages supporting a `filter`-style function, and `filter` is by far the most common choice, arguably favored even more consistently than `map` <https://en.wikipedia.org/wiki/Filter_(higher-order_function)>:

  Filter: 17
  Select: 4
  Special syntax: 3
  FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a closure)
  Where: 1 (C#, in LINQ)
  CopyIf: 1 (C++, bizarre signature)
  FindAll: 1
  Grep: 1
  RemoveIfNot: 1

* `reduce` is extremely popular among functional languages because it's a primitive list-handling operation, although it's a little less common among mainstream languages than the other two. It *does* actually have an alternate name, `fold`, which is nearly as common as `reduce`. However, languages using `fold` are usually those which support both leftward- and rightward-reducing versions of the operation, whereas languages using `reduce` usually don't. Swift falls into the second camp. From Wikipedia's 39-language list <https://en.wikipedia.org/wiki/Fold_(higher-order_function)>:

  Reduce: 20 (with both left and right: 4)
  Fold: 18 (with both left and right: 12)
  Inject: 3
  Special syntax: 3
  Aggregate: 1 (C#, in LINQ)
  Accumulate: 1 (C++, bizarre signature)
  Partition: 1
  ToIterator: 1

(Note that, although I *would* have counted the -ed or -ing forms of these names with the originals, I don't believe I saw any.)

Great research. Thanks for doing this.

Another illustration of the strength of these names: Google named a distributed computing project MapReduce, and everyone basically understood what it meant.

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.

(Incidentally, I think if we *do* decide to rename the main higher-order list APIs, they would be better named as `mapping(to:)`, `flatMapping(to:)`, `filtering(by:)`, and `reducing(from:with:)`. Unlike `sorted`, the parameters are mandatory and deeply necessary to understand what the call does, so they deserve grammatical labels. Grammatical labels usually imply -ing form, not -ed form. If we want to address Dave's complaint about the ambiguity of `filter`, we might rename that to `selecting(where:)`, which is crystal clear about whether it keeps the true elements or the false ones.)

It would seem strange in one way to get rid of such strong terms of art (and also since they are nice and short, they are easy to glance at), but it also seems very inconsistent to keep them. These are methods that will be used by new programmers to Swift, so is it better to keep the existing terms or to modify them?

Say my type has a method filtered(with: Author), is it then strange that I am changing tense within the method’s implementation?

filtered(with author: Author) -> [Item] {
  return items.filter{ $0.author == author }
}

Would it not make more sense to write?

filtered(with author: Author) -> [Item] {
  return items.filtered(where: { $0.author == author })
}

dropFirst => droppingFirst
dropLast => droppingLast

Here, however, I think you're being under-ambitious.

* Even with a nonmutating suffix, `dropping` carries such a strong connotation of deletion that I think it's a poor choice. I would prefer `skipping`, which is much more clearly an operation that doesn't change anything (and finds precedent in other languages—`skip*` functions are a common alternative name for `drop*` functions.)

+1 to skipping

* The `First` and `Last` suffixes are inappropriate for the versions of this function which take an argument. These are inverse operations to `prefix(_:)` and `suffix(_:)`, and should be named accordingly.

* `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` are sort of strange, because they're tied deeply into indices and aren't closely related to the other prefix/suffix methods. I would at least seriously consider renaming these to `upTo(_:)`, `through(_:)`, and `from(_:)`—or perhaps even reimagine these entirely as subscripts `[upTo:]`, `[through:]`, and `[from:]`.

I really like the subscript idea. Named subscripts are not used nearly enough as they could. This gives these similar index-related operations a common home, and I believe would work well with autocomplete after typing a `[`.

I could even imagine a `[filtering:]` / `[where:]` / `[passing:]` instead of `filtered()`, but can imagine it might be unpopular.

This is the area where the term-of-art argument is weaker, the API is more inconsistent and difficult to understand, and the methods are more rarely seen and so more important to be understandable without remembering them. All of these factors combine to make the gains from rationalizing them greater.

`map`, `flatMap`, `filter`, and `reduce` are in some ways the "sexy" targets: We use them all over the place, and changing them would "fix" more lines of code. But these calls are so common, and so heavily precedented, that few users will be confused by them—they've probably seen them before Swift, and even if they haven't, they'll see them enough to keep their meanings fresh in their minds. It is the dimmer, less loved corners of the standard library which we ought to focus on, because they stand to benefit much more from following the conventions than the things we use constantly.

`filter` is the big one to me, as it is a common verb that people are likely to use in their own `filtered-` methods. `reduce` is also a common verb, so it does make sense to change to `reducing`, however I don’t imagine many people will be writing their own `reducing-` methods, and similarly `mapping-`, so these possibly fall more into the terms of art category for me; `filtered` is the most important one. Besides, the word 'map' always suggests to me that a new array/sequence will be returned, and never replace each item by mutation.

`filtered`: +1
`reducing`: +0.7
`mapping`: + 0.2

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

VladimirS · June 17, 2016, 12:12pm

    -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 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote:

On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dabrahams · June 20, 2016, 9:27pm

I beg to differ. “<noun>, <verb>ed” is still a noun phrase and as such
should not have side-effects, which rules out mutation.

···

on Thu Jun 16 2016, Patrick Pijnappel <swift-evolution@swift.org> 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.

--
Dave