<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 Jan 23, 2016, at 11:53 AM, Dave Abrahams 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 class=""><br class="">on Fri Jan 22 2016, David Owens II <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Be Grammatical<br class=""><br class="">When a mutating method is described by a verb, name its non-mutating<br class="">counterpart according to the “ed/ing” rule, e.g. the non-mutating<br class="">versions of x.sort() and x.append(y) are x.sorted() and<br class="">x.appending(y).<br class=""></blockquote><br class="">Is this guideline suggesting that we should design our APIs to<br class="">generally have both mutating and non-mutaging counterparts?<br class=""></blockquote><br class="">Definitely not.<br class=""><br class=""><blockquote type="cite" class="">As other have pointed out, this is also very hard to do all the<br class="">time. I think the alternatives are worse. <br class=""></blockquote><br class="">The alternatives to always creating mutating/nonmutating pairs? What<br class="">alternatives have you considered, and what do you see the consequences<br class="">to be?<br class=""><br class=""><blockquote type="cite" class="">It would be nice if there were a way to annotate all member functions<br class="">as mutating/non-mutating to really by-pass this ambiguity.<br class=""></blockquote><br class="">I don't know what you mean by that. Can you explain?<br class=""><br class="">FWIW, there are potential language-level approaches to this problem<br class="">(e.g. <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>),<br class="">but in the absence of language features, it's something we need a<br class="">convention for.<br class=""></div></div></blockquote></div><br class=""><div class="">Exactly. It seems like this convention is a work-around for a language design deficiency. In the case of value types, there are indeed other solutions that could even allow the same name for functions to be used for both mutating and non-mutating. The key thing of importance is bringing that clarity to the call site.</div><div class=""><br class=""></div><div class="">I think there are some interesting proposals in the link provided. Another potential:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">var items = [...]</font></div><div class=""><font face="Menlo" class="">mut items.sort() // sorts the items in-place</font></div><div class=""><font face="Menlo" class="">let copy = items.sort() // sorts a copy of the items and returns that copy</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><span style="font-family: Menlo;" class="">let items = [...]</span></div><div class=""><font face="Menlo" class="">mut items.sort() // error: unable to mutate a constant value</font></div></blockquote><div class=""><br class=""></div><div class="">The other potential thing to look it is what it means for class-types to allow mutation. I simply cannot trust a class-type that has a function named with the correct guidelines or an "InPlace" suffix to actually return a real copy of the class type.</div><div class=""><br class=""></div><div class="">I guess my point is this: codifying a convention seems pre-mature as that convention doesn't bring the safety goals of the language into a place that's verifiable. All of the other guidelines are simply about clarity of use, this convention has a far reaching impact.</div><div class=""><br class=""></div><div class="">-David</div></body></html>