on Thu Jun 16 2016, David Waite <[email protected]> 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 >> <[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 > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
