[swift-evolution] When to use argument labels (a new approach)
jordan_rose at apple.com
Tue Feb 2 21:47:06 CST 2016
I tend to agree with Paul and Charles' concerns here. I think it's still missing Erica's point about some paramaters being more tightly coupled to each other than to the base name. That's sort of addressed with this:
> a.moveTo(x: 300, y: 400) // "a, move to 300" is a sentence
> // but doesn't describe the primary
> // semantics, which are to move in both
> // x and y. Thus, x gets a label.
but I think "describing the primary semantics of the call" could be more explicit. Even just the word "fully [describing]" would help. Given that, "a.tracksHavingMediaType(.WaxCylinder, genre: .Jazz)" would be incorrect, because you can't ignore the "genre" part when describing the call. 'tracks(mediaType:genre:)' or 'tracksMatching(mediaType:genre:)' would both be fine, though the former includes a new convention that plural noun basenames mean filtered fetches.
Then the next problem is that the first version of the library may only have one form, and "tracksMatching(mediaType:)" would seem redundant, so it's just "tracksMatching(_:)". Then the two-argument form is added later, and suddenly they're not quite symmetrical. On second thought, maybe that's okay as long as they have the same base name.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution