[swift-evolution] When to use argument labels, part DEUX

Dave Abrahams dabrahams at apple.com
Mon Feb 8 00:14:32 CST 2016

on Sun Feb 07 2016, David Hart <swift-evolution at swift.org> wrote:

> Re-sending because did not appear on mailing list correctly:
> For me, it means the wrong thing.

  moveFrom(b, to: c)

implies the wrong meaning?  What meaning does it imply to you?

> Swift is not Objective-C. Even if it shares the concept that method
> and parameter names form the signature, the parentheses declaration
> and call syntax (modeled on C languages) increases the visual and
> semantic separation between method and parameter names.
> That's why, the way I see it, method names should stand on their own,
> without the help of parameter names. I should be able to read the
> method calls without the parameter names (like in C) and still
> understand the basic idea:
> a.dismiss(true)
> a.dismissAnimated(true)
> a.tracksWithMediaType(b, c)
> a.move(b, c)
> All these calls, as often seen in C-based languages, are much more
> ambiguous without their parameter names, but still read fine. 

I understand your philosophy, but I disagree with it (I also don't agree
that any of the above “read fine” for their intended semantics).  Swift
lets API designers specify argument labels that are required at the call
site because of a fundamental belief that it makes for better code. This
is a core idea in Swift's design.  IMO, asking API designers to write
code as though the argument labels could be omitted at the call site
would be making their life needlessly difficult.  It would also be out
of touch with reality, since after all the labels *can't* be omitted.

> But:
> a.moveFrom(b, c)
> This reads much worse.
> I'm sorry, I feel like I'm bad at explaining my reasoning. 

I am forced to agree, here.

> One rule I'd like to see is that the method name before the
> parentheses should read fine without the parameter names. That they
> should come as a nice addition to document and disambiguate.

Noted. I won't be proposing that rule, since I disagree with it, but you
can always propose an amendment to the guidelines we end up with and see
how it flies.


More information about the swift-evolution mailing list