<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=""><div class="">As another member of the “anti-fan-club” for the unnamed first parameter, I have to ask: what would be wrong with:</div><div class=""><br class=""></div><div class="">- single-argument functions: default to unnamed “first” (really: only) parameter</div><div class="">- multi-argument functions: default to all-named parameters</div><div class=""><br class=""></div><div class="">…(other than the obvious inconsistencies/special-casing so introduced)?</div><div class=""><br class=""></div><div class="">I mean more in terms of design goals/readability concerns.</div><div class=""><br class=""></div><div class="">The API guidelines seem to address two scenarios for multi-argument functions:</div><div class=""><br class=""></div><div class="">- functions in which one argument is the "semantic focus” (and thus deserves to be the first argument, with its description folded-into the method name)</div><div class="">- functions in which all arguments are “co-equal participants” and have *identical* semantic roles, in which case all parameters should go un-named (e.g. ==, zip, etc.)</div><div class=""><br class=""></div><div class="">…but don’t address a third scenario, wherein:</div><div class=""><br class=""></div><div class="">- there are multiple arguments</div><div class="">- no one argument is the obvious, natural “semantic focus” of the method (thus there’s no natural candidate for which argument’s label ought to get folded-into the method name)</div><div class="">- the arguments all have distinct logical-roles within the method (thus the all-unnamed approach is not great)</div><div class=""><br class=""></div><div class="">…which scenario I think is not all that uncommon in application code (anecdotally 15-30%, depending on problem domain)?</div><div class=""><br class=""></div><div class="">As an example, consider something like this:</div><div class=""><br class=""></div><div class="">protocol PresentationController {</div><div class=""> typealias Content</div><div class=""> typealias PresentationUpdate</div><div class=""><br class=""></div><div class=""><div class=""><div class=""> // one of these feels right:</div><div class=""> func inferPresentationUpdate(fromPrevious previous: Content, toCurrent current: Content) -> PresentationUpdate</div></div><div class=""> func inferPresentationUpdate(from previous: Content, to current: Content) -> PresentationUpdate</div></div><div class=""><br class=""></div> // none of these feels right:<br class=""> func inferPresentationUpdateFrom(content: Content, toCurrent current: Content) -> PresentationUpdate<br class=""> func inferPresentationUpdateFrom(content: Content, to current: Content) -> PresentationUpdate<br class=""> func inferPresentationUpdateFromPrevious(content: Content, toCurrent current: Content) -> PresentationUpdate<br class=""> func inferPresentationUpdateFromPrevious(content: Content, toCurrent current: Content) -> PresentationUpdate<br class=""><br class=""> // nor do any of these:<br class=""> func inferPresentationUpdateTo(content: Content, fromPrevious previous: Content) -> PresentationUpdate<br class=""> func inferPresentationUpdateTo(content: Content, from previous: Content) -> PresentationUpdate<br class=""> func inferPresentationUpdateToCurrent(content: Content, fromPrevious previous: Content) -> PresentationUpdate<br class=""><div class=""><div class=""><div class=""> func inferPresentationUpdateToCurrent(content: Content, from previous: Content) -> PresentationUpdate</div></div></div><div class=""><div class=""><div class=""></div><div class=""><div class=""></div></div></div><div class=""><div class=""></div><div class=""></div></div></div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">…which is as always a bit contrived, but illustrates a scenario wherein neither parameter is arguably the natural "semantic focus” of the method.</div><div class=""><br class=""></div><div class="">(If you need to be convinced this shouldn’t be a method on `Content`, consider that `Content` may be a simple model entity, and that different types of “presentations” may differ in how they want to present model *updates* to the user).</div><div class=""><br class=""></div><div class="">But that’s my 2c; I don’t like the inconsistency, I understand the stated reasons for it, but I think multi-argument methods w/out an obvious “semantic focus” are common enough to deserve consideration.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 24, 2016, at 6:32 AM, Charles Constant 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" class=""><div class="">> <span style="font-size:13px" class="">With our current Objective-C style, we need to repeat at least one word and often need to include "with", "by", "using", etc. to make it read nicely</span></div><div class=""><br class=""></div>When it comes to my own code, I agree with you 100%. However, if I understand the Swift team's rationale, using a label for the first argument is more often than not, bad form. <div class=""><br class=""></div><div class=""><div class="">The point I was trying to make with the pros/cons bullet points is that, even being charitable with the cons and understated about the pros, the change still makes more sense.</div><div class=""><br class=""></div></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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>