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

Dave Abrahams dabrahams at apple.com
Fri Jun 17 16:33:34 CDT 2016


on Thu Jun 16 2016, David Waite <swift-evolution at 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.

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

> -DW
>
>> On Jun 16, 2016, at 1:53 PM, Adrian Zubarev via swift-evolution
>> <swift-evolution at 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 at swift.org
>> <mailto:swift-evolution at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave



More information about the swift-evolution mailing list