On 17.06.2016 0:07, Gmail via swift-evolution wrote:
-0.5
I find the "term of art" argument strong in this case, especially for
map/filter/reduce.
These functions are different than for example `sort` because there can’t
be a general mutating method of `map`. A variable of type `[A]` can’t be
mutated to hold a `[B]` which would be the result of a map from `A -> B`.
Can you compare 'filter' vs 'sort' ? I.e. it is possible to have in-place
filter. Just like 'sort'. Why 'sort' is not a term-of-art but "filter" is?
Even more, I'm confused right now, how should I name my own method in type
that will filter it in-place(i.e. mutating method)?
So, even I think we can leave map/reduce as-is, IMO 'filter' should be
excluded from this group.
I acknowledge that it’s more consistent, and that - by being a suffix to
the function name - autocompletion would still result in the
correct function. However, I don’t find that the extra -ed/-ing suffixes
provide a lot of extra clarity
On 16 Jun 2016, at 12:51, Patrick Pijnappel via swift-evolution
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
