<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 24 Feb 2017, at 02:05, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><ul class="MailOutline"><br class=""><li class="">Regarding the question of the trailing argument to distinguish overflow-checking vs expanding versions of multiplied: rather than add an enum or use the void trick in order to do this via arguments, it is better to just distinguish the two functions via different base names.</li></ul></div></div></div></div></blockquote><br class=""></div><div>Regarding trailing arguments, any chance we could get you to weigh in on on the "Allow trailing argument labels" discussion?</div><div>Personally I like the idea of using the trailing arguments, but not having to use enums to do it; a proper language feature could make it more viable. One variation discussion could for example looking like:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let result = a.adding(b):reportingOverflow</font></div><div><br class=""></div><div>Think of the trailing "argument" as a kind of selector, telling Swift which specific version of the adding method you want to invoke. I prefer this to elongated method names, but maybe others wouldn't.</div><div><br class=""></div><div>If there's appetite for that style though then it would make sense to implement the language feature first, rather than creating inconsistencies now.</div></body></html>