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

[T.J. Usiyan]

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 at 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 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.
>>
>> -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) 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 at swift.org
>> 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
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160616/1bc5095e/attachment.html>