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 < [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. > > -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]) 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
