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

[David Hart]

Re-sending because did not appear on mailing list correctly:

For me, it means the wrong thing.

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

a.moveFrom(b, c)

This reads much worse.

I'm sorry, I feel like I'm bad at explaining my reasoning. 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.

David.

> On 06 Feb 2016, at 03:03, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Fri Feb 05 2016, David Hart <swift-evolution at swift.org> wrote:
> 
>>> Again, I understand the aesthetic preference for this form; I even
>>> prefer it myself.  On the other hand, it seems to me that the difference
>>> between the two forms reflects a point of emphasis that isn't crucial to
>>> understandability at the use-site.  That's why I'm asking whether you
>>> *can't live with* the results.  Are you merely expressing a strong
>>> preference, or are you saying the first form is too awful to abide?
>>> 
>>>> But I’m not sure how to write a simple rule to explain this reasoning.
>>> 
>>> Any *additional* rule is more complexity in the guidelines, which would
>>> have to pay for itself in some objective terms.  Since (I'm assuming
>>> you'll agree that) it doesn't make a difference to understandability,
>>> what objective criteria would you use to justify accomodating cases like
>>> this?
>> 
>> I’m not an extreme enough person to say that it’s too awful to abide
>> :), but I definitely lie more on that side of the fence than the
>> simple strong preference.
>> 
>> To come back to your other examples, even if I prefer the forms you
>> described in your new thread:
>> 
>> a.dismiss(animated: b)
>> a.tracksWith(mediaType: b, composer: c)
>> 
>> The alternatives:
>> 
>> a.dismissAnimated(b)
>> a.tracksWithMediaType(b, composer: c)
>> 
>> Shock me much much less than:
>> 
>> a.moveFrom(b, to: c)
>> 
>> That last one is many times less readable to me.
> 
> Can you explain in what way it is less readable?  Do you mean "it just
> sticks in my craw," or do you mean "I don't know how to intepret it,"
> or, "it means the wrong thing," or...?
> 
> Again, I can understand your preference for it, but to justify making a
> special rule for it I need some kind of objective reasoning.
> 
> -- 
> -Dave
> 
> _______________________________________________
> 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/20160207/af910a6d/attachment.html>