[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