[TillE]

I hope they do adopt that suggested change to method calls. Swift is a nice language, but there's still some awkwardness due to its required compatibility with Objective C. I think if you don't come from that background, then having all named arguments except the first one seems really arbitrary and nonsensical.

[ceeK]

To be honest, even as a fairly seasoned iOS developer I still prefer to have a non-optional first argument in my APIs.

Whereas the post's example compares:

  path.addLineToPoint(CGPoint(x: 100, y: 0))
  -- to -- 
  path.addLineTo(CGPoint(x: 100, y: 0))

I've been doing it as so:

  path.addLine(toPoint: CGPoint(x: 100, y: 0))

...requiring the "toPoint", which can swapped out true method overloading style:

  path.addLine(toArc:...)

In your internal method implementation, Swift allows you to replace the external method name with an internal one, so that it's still nice to work with:

  func addLine(toPoint point: CGPoint) {
  ...
  }

I personally think it's a lot more readable. Otherwise the first argument has to have a really descriptive class name (recommended for sure, but often not the case).

[nardi]

The point here (no pun intended) is to stop repeating noun phrases at the call site. Your call site says "point" twice for no reason:

    path.addLine(toPoint: CGPoint(x: 100, y: 0))

See the "toPoint: CGPoint". It's useless repetition. The new form eliminates it:

    path.addLineTo(CGPoint(x: 100, y: 0))

It's clear you're adding a line to a point, because it says "Point" right there. Even if you have a variable for this point already, it works great:

    path.addLineTo(point)

Or maybe this is a more specifically named point?

    path.addLineTo(centerPoint)

It's clear from all that you're adding a line to a point. Swift has an emphasis on concise syntax, and removing the repetition, IMO, is a nice win in readability.

[ceeK]

You do have a good point, and something I didn't explicitly notice before. This does seem to have the indirect consequence of enforcing some sort of type information in the variable name, but I expect many iOS developers do that regardless.

It'd also be interesting to see the impact on readability when you have longer variable names. `point` definitely makes it more concise here. But if you had several points within the same scope, readability may suffer given type information is typically at the end of a variable name?

  path.addLineTo(childViewTopLeftPoint)
  path.addCurveTo(childViewTopRightPoint, withControlPoint1: arbitrary1Point, andControlPoint2: arbitrary2Point)

  path.addLine(toPoint: childViewTopLeftPoint)
  path.addCurve(toPoint: childViewTopRightPoint, withControlPoint1: arbitrary1Point, andControlPoint2: arbitrary2Point)

I feel the second version here allows me to bypass obtaining the type information "..Point" from the variable name when reading.

Interestingly, I wonder how this type of method would be converted:

  addArcWithCenter(center: CGPoint, radius: CGFloat, startAngle: CGFloat, endAngle: CGFloat, clockwise: Bool)

You'd perhaps think of addArcWith(center: CGPoint), but then you'd need to have 'center' in the variable name to convey meaning. Keeping addArcWithCenter maintains obj-c status quo. addArc(withCenter: CGPoint) is more Swifty, but you may have repetition if your variable is named centerPoint, or similar. I have a feeling it would be kept as is.

[seivan]

Yup, that's what I would like. It's silly to remove the point from the method name and not makes it into a named argument that could be overloaded for others. I might just do that for my own stuff. I don't like the notion of the first argument not being in either the method name or as a named argument.

[equalarrow]

There has been discussion on one of the Swift lists (forget which one off the top of my head) to require first param. So this is definitely a known and active (still) topic.

[ChrisLTD]

I would screw up that first named argument thing every time if it weren't for Xcode's autocomplete.