[swift-evolution] named parameters - why hidden first?/proposal interest

[plx]

As another member of the “anti-fan-club” for the unnamed first parameter, I have to ask: what would be wrong with:

- single-argument functions: default to unnamed “first” (really: only) parameter
- multi-argument functions: default to all-named parameters

…(other than the obvious inconsistencies/special-casing so introduced)?

I mean more in terms of design goals/readability concerns.

The API guidelines seem to address two scenarios for multi-argument functions:

- 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)
- 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.)

…but don’t address a third scenario, wherein:

- there are multiple arguments
- 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)
- the arguments all have distinct logical-roles within the method (thus the all-unnamed approach is not great)

…which scenario I think is not all that uncommon in application code (anecdotally 15-30%, depending on problem domain)?

As an example, consider something like this:

protocol PresentationController {
  typealias Content
  typealias PresentationUpdate

  // one of these feels right:
  func inferPresentationUpdate(fromPrevious previous: Content, toCurrent current: Content) -> PresentationUpdate
  func inferPresentationUpdate(from previous: Content, to current: Content) -> PresentationUpdate

  // none of these feels right:
  func inferPresentationUpdateFrom(content: Content, toCurrent current: Content) -> PresentationUpdate
  func inferPresentationUpdateFrom(content: Content, to current: Content) -> PresentationUpdate
  func inferPresentationUpdateFromPrevious(content: Content, toCurrent current: Content) -> PresentationUpdate
  func inferPresentationUpdateFromPrevious(content: Content, toCurrent current: Content) -> PresentationUpdate

  // nor do any of these:
  func inferPresentationUpdateTo(content: Content, fromPrevious previous: Content) -> PresentationUpdate
  func inferPresentationUpdateTo(content: Content, from previous: Content) -> PresentationUpdate
  func inferPresentationUpdateToCurrent(content: Content, fromPrevious previous: Content) -> PresentationUpdate
  func inferPresentationUpdateToCurrent(content: Content, from previous: Content) -> PresentationUpdate

}

…which is as always a bit contrived, but illustrates a scenario wherein neither parameter is arguably the natural "semantic focus” of the method.

(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).

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.

> On Jan 24, 2016, at 6:32 AM, Charles Constant via swift-evolution <swift-evolution at swift.org> wrote:
> 
> > 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
> 
> 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. 
> 
> 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.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160124/08dc82a6/attachment.html>