[swift-evolution] named parameters - why hidden first?/proposal interest

[Tino Heth]

> We believe fairly strongly that Swift’s design here reflects the appropriate defaults for clear, expressive APIs and code. The API Design Guidelines line up with the default behavior of Swift for a reason. Repeating the “Objective-C legacy” trope strongly implies that you’re not considering the rationale behind Swift’s design, and weakens your arguments considerably.
I'm not saying the influence of Objective-C is bad (therefore, I used the quotation marks), but imho it's pointless to deny that it exists.

>> say(message: "Hello", times: 4)
> 
> The message is the direct object of the verb “say”, so the first argument being the message is implied. Clarity is not improved by having the “message:” argument label.
I wouldn't force anyone to use that label — and I think this topic was not started because of a lack of clarity, but an excess of different rules.

>> say("Hello", 4)
> 
> This is less clear than your initial example. There is absolutely nothing to indicate, at the call site, that “4” is a repeat count.
Here as well: The use of a label should not be discouraged — but you can't fight against users who (for whatever reason) want to use calls that are hard to understand.

>> Labels are "just" an aid for programmers, but for the program itself, they have not much more meaning than a comment:
> 
> That is incorrect. The argument labels are a fundamental part of the name of a Swift function (or initializer, or subscript).
I guess that sentence failed in expressing my thoughts:
Of course, labels have influence on method/selector resolution — but their raison d'être is to help programmers to write calls that are easy to understand: Many languages have no labels for parameters, and afair, there has been at least one bridge (Cocoa for Java?) that had to get rid of them. 

>> Higher-order functions already ignore labels completely and rely on positions only.
> 
> That’s mostly correct; our model around argument labels with function types is fuzzy and needs work.

Taking a statement from another thread:
> Right now, you'll still need to use labels in the call. However, this is an area where we'd like to revisit things a bit: having labels in function types seems to cause more trouble than it provides benefits, and I'd like to see up address that directly.
So you say that there are situations where labels are bad, right? So it would be necessary to define rules on how to get rid of them as well...

>> So, instead of complicated rules enforced by the compiler, I would prefer a simple system backed by conventions that discourage programmers to fall back to C-style calls where you have to count parameters to decipher their meaning.
> 
> So… you want a plethora of conventions that differ from one project to the next,
No. I don't think there would be an urge to establish a different set of conventions for each project/team.

> rather than a set of default language rules backed by the API Design Guidelines? I admit that one will often do a double-take when first encountering the rules for which arguments have labels by default, but I’d rather learn that once than have widely differing approaches to when argument labels are provided vs. dropped.
I think you are underestimating the importance of conventions — in the area of code comprehensibility, they are far more powerful than anything that can be enforced by a compiler.

There has been another discussion about something that's optional and should become mandatory (self). I'm glad that proposal was rejected, as I think it's not that hard to define a set of guidelines when to use "self." and when to skip it, but it shouldn't be the job of the compiler to enforce rules whose only justification is to make source more accessible to human readers.
Imho labels are very similar in this aspect, with the difference that right now, there is a quite complicated scheme embedded in the compiler. Moving that responsibility to the party that actually is affected by the choice (we as developers) would make the language simpler and more elegant.

Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/3c3cfa7e/attachment.html>