[swift-evolution] When to use argument labels (a new approach)

Dave Abrahams dabrahams at apple.com
Wed Feb 3 16:31:58 CST 2016

on Tue Feb 02 2016, Jordan Rose <swift-evolution at swift.org> wrote:

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

Not “sort of” :-).

It's addressed, in practice, by the “primary semantics” clause.  When
the association between the first and second parameters is stronger than
the relationship between the first parameter and the base name, the
primary semantics will not be described by the a sentence that ends with
the first argument.  As I wrote in an earlier message, it's important to
find minimal rules that cover everything we want to express in practice.

> but I think "describing the primary semantics of the call" could be
> more explicit. Even just the word "fully [describing]" would help.

I don't see how.  That would imply that, in order to omit the argument
label, any parameters after the first must have no semantic effect at

> 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.
> Jordan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list