<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 26 Apr 2016, at 14:48, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">Should the syntax be `<font face="Menlo" class=""><span class="" style="font-size: 11px;">x.=f()</span></font>`? — Not necessarily. I kinda like James Campbell's idea of a `<font face="Menlo" class=""><span class="" style="font-size: 11px;">mutate</span></font>` keyword. Consider the following:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span class="" style="font-size: 11px;"> <span class="Apple-converted-space"> </span><b class="">var</b><span class="Apple-converted-space"> </span>numbers = [5, 12, 6, 2]</span></font></div><div class=""><font face="Menlo" class=""><span class="" style="font-size: 11px;"> <span class="Apple-converted-space"> </span><b class="">mutate</b><span class="Apple-converted-space"> </span>numbers.append(10)</span></font></div><div class=""><font face="Menlo" class=""><span class="" style="font-size: 11px;"> <span class="Apple-converted-space"> </span><b class="">mutate</b><span class="Apple-converted-space"> </span>numbers.sort()</span></font></div><div class=""><font face="Menlo" class=""><span class="" style="font-size: 11px;"> <span class="Apple-converted-space"> </span><b class="">if let</b> </span></font><span class="" style="font-family: Menlo; font-size: 11px;">biggest</span><font face="Menlo" class=""><span class="" style="font-size: 11px;"> =<span class="Apple-converted-space"> </span><b class="">mutate</b><span class="Apple-converted-space"> </span>numbers.popLast() {</span></font></div><div class=""><font face="Menlo" class=""><span class="" style="font-size: 11px;"> print("The biggest number was:", biggest)</span></font></div><div class=""><font face="Menlo" class=""><span class="" style="font-size: 11px;"> }</span></font></div><div class=""><br class=""></div><div class="">So `<font face="Menlo" class=""><span class="" style="font-size: 11px;">mutate</span></font>` would work much like `<font face="Menlo" class=""><span class="" style="font-size: 11px;">try</span></font>` but—unlike `<font face="Menlo" class=""><span class="" style="font-size: 11px;">try</span></font>` which can move further to the left—`<font face="Menlo" class=""><span class="" style="font-size: 11px;">mutate</span></font>` would have to always prefix the mutating receiver.<span class="Apple-converted-space"> </span></div></div></blockquote><div class=""><br class=""></div><div class="">That doesn't look so bad (we might shorten 'mutate' to 'mut', though I don't think that would be really necessary).</div><div class="">I'm wondering how to deal with fluent interfaces which do mutate the receiver and return 'self', i.e. the builder pattern. I think we can simply require that such a chained expression is required to consist of only mutating calls (or only non-mutating calls), so that one 'mutate' for the whole expression would be sufficient.</div><div class="">Expressions combining mutating calls to different receivers which have return values would simply be prohibited. This would probably be bad style anyway (contrary to the fluent example), or does anyone have a good counter example?</div></div></div></blockquote><br class=""></div><div>If we do go ahead with this then put me in the “mutate” camp, as I’d actually prefer to see & on inout variables be replaced by the inout keyword at the call-site for consistency. That said, the reason I want that is because inout variables are fairly uncommon (though with indexing changes that will change), but it also looks fairly ugly IMO.</div><div><br class=""></div><div><br class=""></div><div>Still, for the feature itself I’m of two minds; the naming convention was just changed to enable clear distinctions between mutating and non-mutating methods, but if we had this feature that distinction wouldn’t actually be necessary, we can just call all forms of sorting .sort() and the mutate keyword (or lack of) would distinguish which one is meant, and failure to use a return value would pick up on mistakes. I’d hate to go through the whole naming debate again, but at the same time that would be simpler in a way.</div><div><br class=""></div><div><br class=""></div><div>So I’m a +1 if we can also use it to roll mutating and non-mutating methods under the same name, even though I don’t want to go through the naming transition all over again ;)</div></body></html>