-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 > <[email protected]> wrote: > > +1 very much for consistency. > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution > ([email protected] <mailto:[email protected]>) 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
