<div dir="ltr">After hitting Send button, I remembered that &quot;Enhanced floating-point protocols&quot; proposal uses `add`, `subtract`, `multiply` and `divide` names for mutating versions.<div>They should be non-mutating by default, as well as other purely mathematical terms. I don&#39;t know how it can be unobvious.</div><div><br></div><div>- Anton</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-15 23:36 GMT+03:00 Антон Жилин <span dir="ltr">&lt;<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad.<div>It&#39;s more a matter of what should be &quot;default&quot; in a specific domain.<div><br></div><div>In imperative domain, mutating version usually feels as the most natural one.</div><div>Think `sort`. Everyone knows that sort must modify the array (usually through a sequence of swaps) to be most efficient. (Heapsort is an exception there, I guess.)</div></div><div>That&#39;s why it is mutating version should be the shorter one, and non-mutating should have a prefix or a suffix.</div><div><br></div><div>In functional domain, non-mutating version usually feels as the most natural one.</div><div>Think `filter`, `map`, `reduce`. This functions originated in functional languages. Functional languages usually have immutability by default.</div><div>When we &quot;map&quot; these idioms to Swift, we should let non-mutating version be the &quot;default&quot; one.</div><div>Of course, we can be strict with our own rules and inventive in terms of function names, but we just shouldn&#39;t.</div><div><br></div><div>Think `union`, `intersection`. These terms originated from mathematics, where mutability just doesn&#39;t exist.</div><div>Given such a domain area, it should be obvious that `union` on a set means non-mutating version, unless stated otherwise.</div><div><br></div><div>So, I conclude that we should not enforce any guideline about naming mutating/non-mutating versions of methods.</div><div>Correct me if this is a wrong conclusion.</div><div><br></div><div>- Anton</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-04-15 19:31 GMT+03:00 Erica Sadun <span dir="ltr">&lt;<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr">I&#39;ve already expressed these concerns, but nobody noticed, apparently. Here is it:<div><br></div><div><span style="font-size:12.8px">I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">`InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we?</span><br style="font-size:12.8px"><span style="font-size:12.8px">I liked the proposal about new naming conventions, but overlooked this change.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Many people will agree with me. This still can be reviewed until Swift 3.</span><br style="font-size:12.8px"><span style="font-size:12.8px">If so, I will create a proposal to correct &quot;the big three&quot; in this.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">What do you think?</span></div></div></div></blockquote><br></div></span><div>I would like to see a formal proposal along these lines. My other suggestions <a href="http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/" target="_blank">are here</a>.</div><span><font color="#888888"><div><br></div><div>-- E</div><div><br></div><br></font></span></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>