<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 29 Jan 2016, at 20:23, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class="">on Fri Jan 29 2016, Adriano Ferreira <<a href="http://adriano.ferreira-AT-me.com" class="">adriano.ferreira-AT-me.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Indeed, Ruby has an interesting convention where a question mark (?) is used for boolean functions/methods:<br class=""><br class="">In Swift: foo.contains(...)<br class="">In Ruby: foo.include?(...)<br class=""><br class="">In Swift: foo.isEmpty<br class="">In Ruby: foo.empty?<br class=""><br class="">Well, in the last case `isEmpty` is a property whereas `empty?` is a method, but the idea is similar.<br class=""><br class="">Also, an exclamation mark (!) is generally used to indicate that a function/method mutates `self`:<br class=""><br class="">Non-mutating:<br class=""><br class="">Swift — foo.reverse()<br class="">Ruby — foo.reverse<br class=""><br class="">Mutating:<br class=""><br class="">Swift — foo.reverseInPlace()<br class="">Ruby — foo.reverse!<br class=""><br class="">Non-mutating:<br class=""><br class="">Swift — foo.sort() or foo.sort({…})<br class="">Ruby — foo.sort or foo.sort {…}<br class=""><br class="">Mutating:<br class=""><br class="">Swift — foo.sortInPlace() or foo.sortInPlace({…})<br class="">Ruby — foo.sort! or foo.sort! {…} <br class=""><br class="">I think it’s a simple and nice way of addressing the naming issue of<br class="">mutating vs. non-mutating or pure vs. impure<br class="">functions/methods. However, this conflicts with the syntax sugar of<br class="">Optionals and, therefore, following this path would have a clear<br class="">impact in the language.<br class=""></blockquote><br class="">Please keep discussion of new language features in a separate thread;<br class="">thanks.</div></blockquote><br class=""></div><div>I thought the point was mostly just to highlight how another language has dealt with the same problem? Of course Ruby’s syntax wouldn’t be feasible in Swift, and at the same time I think it’s actually unnecessary to add it so long as a good naming convention is very clear about what something is or does, i.e- </div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo.sort() // Sorts the original</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo.sorted() // Returns a sorted form of the original, leaving the original unchanged</font></div><div><br class=""></div><div>You could do reverseInPlace() instead, but personally I dislike that, though the main problem with the above is how easy it is to make a typo, whereas the operators for mutability would throw errors if used incorrectly. However, if properly declared the mutating vs non-mutating methods shouldn’t actually be easy to misuse either, i.e-</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"><font face="Monaco" class=""> </font></span><font face="Monaco" class="">mutating func sort() -> Void { /* Do some sorting in here */ }</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@warn_unused_result func sorted() -> SomeType { /* Make and return a sorted copy in here */ }</font></div><div><br class=""></div><div>The first declaration can’t be misused because with its return type being void trying to assign it would cause an error, plus the mutating keyword ensures that it won’t be intentionally called on a read-only value.</div><div>The second declaration’s @warn_unused_result ensures that it won’t be misused because it isn’t possible to simply call it, it must be assigned or produce a warning. So this actually reinforces that overly verbose method names like reverseInPlace() are not needed when attempting to convey mutating vs non-mutating behaviour, as the compiler will quickly indicate a misuse.</div><div><br class=""></div><div>The main problem is when a mutating function also needs to be able to return some optional result in addition to mutating itself for example:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>mutating func sort() -> Int { /* Sort self, and return the number of elements that had to be relocated in order to do-so */ }</font></div><div><br class=""></div><div>However I think the easiest fix in this case would be declare it like:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@warn_unused_result mutating func <span style="font-size: 11px;" class="">sortAndCountElementsMoved</span>() -> Int { /* Sort and return number of elements moved */ }</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>mutating func sort() { let _ = self.<span style="font-size: 11px;" class="">sortAndCountElementsMoved</span>(); } // Call the above, but explicitly ignore its result</font></div><div><br class=""></div><div>So eh… in conclusion, I don’t think we need Ruby’s operators as Swift can solve the same problems, though maybe not as succinctly.</div></body></html>