I agree the essence of the "terms of art" can still exist in the base name while applying the "ed/ing rule". I would vote to have these renamed to better align with Swift and less with the terms of art.
-Shawn On Thu, Jun 16, 2016 at 10:41 AM Patrick Pijnappel via swift-evolution < [email protected]> wrote: > Hmm, after some consideration I think we should reconsider renaming all of > the exceptions (map => mapped, filter => filtered, etc). > > The main reason to use a term of art is such that people already familiar > with the term will immediately understand it. However as Jonathan points > out, since the modified terms are very close to the terms of art they are > unlikely to hinder in this objective and any initial confusion would be > very quickly and easily recovered from. Any mental pattern matching would > quickly transfer to the Swift forms. > > – Basically* all benefits of using a term of art still apply.* > – The likelihood, duration and impact of any confusion would all be very > low. > – It'd be a lot more consistent (which also aids the mind to learn to > pattern match on -ed/-ing). > > On Thu, Jun 16, 2016 at 5:51 PM, David Waite via swift-evolution < > [email protected]> wrote: > >> I’ve always considered the term of art argument to be at least partially >> a red herring. >> >> These methods are difficult because you don’t have guarantees of >> non-mutability until you get to Collection - on Sequence, a dropFirst >> method may mean that neither the original nor returned sequence can address >> that item anymore. Names have to indicate that a Sequence may or may not >> consume an item. >> >> It makes me wonder if we should evaluate doing something more aggressive, >> such as eliminating the support of one-time/destructive Sequences >> completely. >> >> -DW >> >> > On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution < >> [email protected]> wrote: >> > >> > >> > on Thu Jun 16 2016, Jonathan Hull <[email protected]> wrote: >> > >> >> …Thus, I don’t really see the harm in renaming these to match the rest >> >> of Swift. It won’t cause any confusion that can’t be easily recovered >> >> from. >> > >> > I'm beginning to think you may be right. >> > >> > -- >> > -Dave >> > >> > _______________________________________________ >> > 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
