<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 11:40 AM, Patrick Pijnappel <<a href="mailto:patrickpijnappel@gmail.com" class="">patrickpijnappel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hmm, after some consideration I think we should reconsider renaming all of the exceptions<font face="arial, helvetica, sans-serif" class=""> (map => mapped, filter => filtered, etc).</font><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">– Basically<b class=""> all benefits of using a term of art still apply.</b></div><div class="">– The likelihood, duration and impact of any confusion would all be very low.</div><div class="">– It'd be a lot more consistent (which also aids the mind to learn to pattern match on -ed/-ing).</div></div></div></blockquote><div><br class=""></div>I believe my points still apply - Sequences may be one time use and thus mutating (such as a socket-backed Sequence). Neither mapped() nor mapping() is universally appropriate.</div><div><br class=""></div><div>-DW</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 16, 2016 at 5:51 PM, David Waite via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’ve always considered the term of art argument to be at least partially a red herring.<br class="">
<br class="">
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.<br class="">
<br class="">
It makes me wonder if we should evaluate doing something more aggressive, such as eliminating the support of one-time/destructive Sequences completely.<br class="">
<br class="">
-DW<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
> On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
><br class="">
> on Thu Jun 16 2016, Jonathan Hull <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
>> …Thus, I don’t really see the harm in renaming these to match the rest<br class="">
>> of Swift. It won’t cause any confusion that can’t be easily recovered<br class="">
>> from.<br class="">
><br class="">
> I'm beginning to think you may be right.<br class="">
><br class="">
> --<br class="">
> -Dave<br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>