+1 I was definitely surprised when these weren't changed with the other methods. They will still be easily found with the new names, and the current inconsistency makes the -ed/-ing rule much harder to grok / trust (especially considering how often these are used).
I do understand David Waite’s objections, but I think that issue needs to be solved separately, as it is also a problem for things like ‘sorted’. It basically affects all “non-mutating” methods on Sequence, and we should come up with a fix for that situation as a whole (in a separate proposal). Thanks, Jon > Due to considerably support on this thread > <http://news.gmane.org/find-root.php?group=gmane.comp.lang.swift.evolution&article=20783 > > <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 > > <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 > <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 > > <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 > > <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 > > <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 > > <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 > > <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 > > <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 > > <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
