<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=""><div class="">FYI this (2/3) has already been sketched out: <a href="https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst" class="">https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst</a></div><div class=""><br class=""></div><div class="">My understanding is that this will be considered in the future, and the naming discussion is something important for now (i.e Swift 2.x-3.x era)</div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 11 Feb 2016, at 23:13, Jarod Long via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Here are some thoughts after having quietly pondered the mutating method naming discussion for a while.</div><div class=""><br class=""></div><div class="">My view is that an "ed/ing" mutation rule is fraught with undesirable compromises. It's tempting because it works so well in the majority of cases, but it seems that cases where it doesn't work are not uncommon, even when the scope of the discussion is narrowed to a small set of operations such as this. We're trying to play nice with English, but we're butting up against its fundamental lack of clarity.</div><div class=""><br class=""></div><div class="">As far as I see it, these are the options (forgive me for repeating much of what others have said -- I'd like to accurately convey my perception of the situation as a whole):</div><div class=""><br class=""></div><div class="">1. Move forward with ed/ing-based guidelines that work well in many cases. For the cases which don't work well, we can either:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Have explicit exceptions, likely leading to overly-complicated guidelines that people may not be bothered to follow.</li><li class="">Leave it up to the developer to decide what's best on a case-by-case basis, likely leading to inconsistencies and lots of time spent on discussions of this magnitude.</li></ul></div><div class=""><br class=""></div><div class="">There's also a worrying amount of uncertainty and subjectivity involved in identifying the situations where the base guidelines don't work well, particularly for developers who aren't experts in English.</div><div class=""><br class=""></div><div class="">2. Use "inPlace" or some other simple adornment that can be universally applied to a method without exceptions.</div><div class=""><br class=""></div><div class="">An inPlace suffix would be a significant eyesore for such a common pattern. There doesn't seem to be another less obtrusive suffix that properly conveys mutation, so we're either stuck with inPlace, or we could try to find a more terse symbolic pattern (the same idea as Ruby's postfix ! to indicate mutation). Nothing desirable comes to mind, though.</div><div class=""><br class=""></div><div class="">3. Add a language-level feature that allows a method on a type which returns a value of that same type to be called in a way that mutates the callee.</div><div class=""><br class=""></div><div class="">Even when naming isn't an issue, defining mutating / non-mutating versions of method is somewhat tedious and inflates the type's interface. Any method that returns a value of the callee's type is a valid candidate for a mutating version of that API, but defining the mutating version is 100% boilerplate.</div><div class=""><br class=""></div><div class="">Support from the compiler would eliminate this boilerplate as well as this seemingly-unsolvable naming problem at the cost of some additional complexity in the compiler.</div><div class=""><br class=""></div><div class="">I can see two options off the top of my head. First, a method that returns the same type as the callee mutates when its return value is unused instead of producing a warning:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> c = a.union(with: b) <span style="font-variant-ligatures: no-common-ligatures; color: #008400" class="">// Doesn't mutate.</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">a.union(with: b) <span style="font-variant-ligatures: no-common-ligatures; color: #008400" class="">// Mutates.</span></div></div><div class=""><br class=""></div><div class="">This is somewhat subtle and has some potential for confusion, but I think Swift's strong immutability features would make it extremely rare for this pattern to create bugs.</div><div class=""><br class=""></div><div class="">Or, we can create a special syntax for mutating a callee with the return value of its method:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="" class="">a .= union(with: b) </span>// First thing that comes to mind. It's conceptually similar to += and friends and makes assignment explicit.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="" class="">a = .union(with: b) </span>// Similar idea, looks less like you're calling a global method called union.</div></div><div class=""><br class=""></div><div class="">My personal preference lies strongly in option 3 with roughly equal preference for either sub-option, but I'd really like to hear what others think.</div><div class=""><br class=""></div><div class="">Jarod</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Feb 11, 2016, at 11:43, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Just thinking out loud here:<div class=""><br class=""></div><div class="">"x's intersection with y" makes sense. So "x.intersection(with: y)" makes sense. That's already in Dave's diff.</div><div class=""><br class=""></div><div class="">Unfortunately the same doesn't work well for "x's union with y" — should "x.union(with: y)" be a mutating or nonmutating operation? Hard to tell.</div><div class=""><br class=""></div><div class="">How about we just move to ∪ and ∪= operators and call it a day? :-)</div><div class=""><div class=""><div class="gmail_extra">
<br class=""><div class="gmail_quote">On Thu, Feb 11, 2016 at 11:36 AM, Erica Sadun <span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Assuming one would want to avoid the -ed suffix (and also -ing), one might consider:</div><div class=""><br class=""></div><div class="">* intersectionOf(), orOf(), unionOf() (or "With" over "Of")</div><div class="">* setIntersection(), setOr(), setUnion(),</div><div class="">* intersectionResult(), orResult(), unionResult(),</div><div class="">etc</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- E</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 11, 2016, at 12:28 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank" class="">jtbandes@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">"intersected" sounds okay to me. "unioned" is borderline, and "ored" is not something I'd want in the standard library. Neither is "oring".<div class="gmail_extra">
<br class=""><div class="gmail_quote">On Thu, Feb 11, 2016 at 11:25 AM, Erica Sadun <span dir="ltr" class=""><<a href="mailto:erica@ericasadun.com" target="_blank" class="">erica@ericasadun.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I see the -ed versions as short for -edSet, with the Set being implied. Under this reasoning, unioned == unionedSet, intersected == intersectedSet, thus acting as nouns not verbs, and used for non-mutating application.</div><div class=""><br class=""></div><div class="">inPlace is only for mutating application. I mildly prefer the shorter union to unionInPlace, although I could argue both sides. (The latter is clearer but longer, the former is the short verb action that the whole guideline thing is supposed to endorse.)</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- E</div></font></span><div class=""><div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Feb 11, 2016, at 12:19 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank" class="">jtbandes@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 11, 2016 at 11:09 AM, Erica Sadun via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><b class="">Non-Mutating, returning new value</b>: unioned(with), intersected(with), exclusiveOred(with)</div><div class=""><br class=""></div><div class="">Reasoning:</div><div class=""><br class=""></div><div class="">* <b class="">I think the -ing endings sound unnatural, stilted, and unmathematical. </b>They make me wince.</div></div></blockquote><div class=""><br class=""></div><div class="">So do the -ed versions, IMO. That's why -InPlace is such a convenient suffix.</div><div class=""><br class=""></div><div class="">Jacob</div></div></div></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>