<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="">Should static/class methods be capitalized, or lower-cased? I have my own convention of capitalizing them, but I don’t know if that’s how most people do it.<div class=""><br class=""></div><div class="">Matt</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 13:14, Paul Cantrell 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="">I took Adriano’s comments not as a specific syntax proposal — clearly Ruby’s use of the ? and ! symbols is both different from and fundamentally incompatible with Swift’s — but rather as a way of pointing out that another language has solved this problem by reserving a special notation for “mutating” instead of trying to pack it in to grammar-based or otherwise natural-langue-based conventions, and that worked out all right.</div><div class=""><br class=""></div><div class="">Turning back to the guidelines review at hand, I do worry that these proposed guidelines pack too much significance into the vagaries of English grammar, which (as we’ve found out on this thread) is an inconsistent and fickle friend. I’m personally in favor of charging ahead with that quixotic venture nonetheless, but I do worry a bit that the guidelines as stated are too narrowly stated in all the places where grammar is involved.</div><div class=""><br class=""></div><div class="">Cheers, P</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 2:55 PM, David Waite 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="">In Ruby ‘?’ indicates conditional usage while in Swift ‘?’ indicates optionality or an optional (fall-back) execution path (this operation returned return nil as a fallback for not holding a value, method being called on a nil value, method call throwing an error, etc)<div class=""><br class=""></div><div class="">This is why in Ruby 2.3, the “?.” operator that they wanted to use eventually evolved into an “&.” operator.</div><div class=""><br class=""></div><div class="">‘!’ in Ruby means either this operation is destructive or that this operation will raise an exception on error, in Swift it means as a general rule ‘failures are precondition failures which will crash your application’</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 11:10 AM, Adriano Ferreira 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="">Indeed, Ruby has an interesting convention where a question mark (?) is used for boolean functions/methods:</div><div class=""><br class=""></div><div class="">In Swift: foo.<b class="">contains(...)</b></div><div class="">In Ruby: foo.<b class="">include?(...)</b></div><div class=""><br class=""></div><div class=""><div class="">In Swift: foo.<b class="">isEmpty</b></div><div class="">In Ruby: foo.<b class="">empty?</b></div></div><div class=""><br class=""></div><div class="">Well, in the last case `isEmpty` is a property whereas `empty?` is a method, but the idea is similar.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Also, an exclamation mark (!) is generally used to indicate that a function/method mutates `self`:</div><div class=""><br class=""></div><div class="">Non-mutating:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Swift — foo.<b class="">reverse()</b></li><li class="">Ruby — foo.<b class="">reverse</b></li></ul></div><div class=""><br class=""></div><div class="">Mutating:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Swift — foo.<b class="">reverseInPlace()</b></li><li class="">Ruby — foo.<b class="">reverse!</b></li></ul></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">Non-mutating:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Swift — foo.<b class="">sort()</b> or foo.<b class="">sort({…})</b></li><li class="">Ruby — foo.<b class="">sort</b> or foo.<b class="">sort {…}</b></li></ul></div><div class=""><br class=""></div><div class="">Mutating:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Swift — foo.<b class="">sortInPlace()</b> or foo.<b class="">sortInPlace({…})</b></li><li class="">Ruby — foo.<b class="">sort!</b> or foo<b class="">.sort! {…}</b> </li></ul></div></div><div class=""><div class=""></div></div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="">I think it’s a simple and nice way of addressing the naming issue of mutating vs. non-mutating or pure vs. impure functions/methods. However, this conflicts with the syntax sugar of Optionals and, therefore, following this path would have a clear impact in the language.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">— A</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 23, 2016, at 3:46 PM, 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" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 23, 2016 at 12:44 PM, J. Cheyo Jimenez via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </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;">The inPlace proposal is excellent. As suggested something like x.=f() would be perfect to distinguish mutating methods .Something I don't like from the API design guidelines is that non mutating methods like enumerate would be become enumerated. In my mind enumerate is a word of art and I don't ever think of it as muting so having to always use enumerated in the future seems weird. Also having to ed/ing non mutating methods seems to make mutating methods more important. <div class=""><br class=""><div class="">//non mutating suggestion</div><div class="">x.sort()</div>x.split()<br class=""><div class=""><br class=""></div><div class="">//other ideas for mutating methods names</div><div class="">x.sort*()</div><div class="">x.sort&() // I like & the most</div>x.split&()<br class=""><div class="">x.sort@()<br class=""><div class=""><br class=""></div>By marking a method with a special character at the end, the reader would know that the method mutates. </div></div></blockquote><div class=""><br class=""></div><div class="">Ruby uses ! for this, by convention: <a href="http://stackoverflow.com/questions/612189/why-are-exclamation-marks-used-in-ruby-methods" class="">http://stackoverflow.com/questions/612189/why-are-exclamation-marks-used-in-ruby-methods</a></div><div class=""><br class=""></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></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=""><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></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=""></div></body></html>