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

[T.J. Usiyan]

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/2882521a/attachment.html>