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

[Douglas Gregor]

> On Jan 22, 2016, at 6:26 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> The other unfortunate thing about this, is that this is another instance where "init" behaves differently then the rest of Swift. I think it would be great to unify this.
> It's definitely confusing that labels receive special treatment in init, and I'm quite sure method declarations would look different without the "Objective-C-legacy”.

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.

> Imho named arguments with default values are a great feature, which I loved since I've seen it the first time R (which would be very hard to use without default values…).
> R, as my reference, is quite flexible with parameters:
> You can leave out all labels, and only rely on the order of the values, you can assign values in whatever order you like — and, up to a certain degree, you can mix:
> myFunc(firstParameterWithoutLabel, secondParameterWithoutLabel, fourthLabel = 8, thirdLabel = 0.5)
> 
> I don't think Swift needs that much flexibility, but imho the compiler could be less strict and leave it to the user weather parameters are identified via label or position.
> 
> say("message", times: 4)
> is a good default and should be offered by autocompletion, but
> 
> 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.

> and even
> 
> say("Hello", 4)
> 
> could be allowed as well (as long as there is no clash with a second say-function).

This is less clear than your initial example. There is absolutely nothing to indicate, at the call site, that “4” is a repeat count.

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

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

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

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160122/6200d226/attachment.html>