[swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

[Kevin Ballard]

This is a valid concern.
 
If we assumed that 50% of methods would have a labelled first parameter, and 50% would leave them unlabelled, and furthermore we assume that all methods with labelled first parameters would use the parameter name as the label, then I would support this proposal purely on the grounds that it's easier to write `func foo(_ bar: T)` than it is to write `func foo(bar bar: T)`.
 
However, if we assume that the majority of methods still want an
unlabelled first parameter (which seems like a reasonable assumption to
me; most of the methods I write would certainly have the first parameter
unlabelled), and similarly if we assume that a non-trivial amount of
labelled first parameters use a different label than the parameter name,
then this change doesn't make as much sense anymore.
 
Another concern with this proposal is that, even if you assume most
methods with multiple parameters would want to label all the parameters,
it's likely that most methods with a single parameter will leave the
parameter unlabelled. But this proposed rule would cause even single-
argument methods to label the sole argument.
 
-Kevin Ballard
 
On Wed, Mar 9, 2016, at 05:03 PM, Jordan Rose via swift-evolution wrote:
> This is my concern too. Our guidelines often lead to the first
> parameter having a label, but usually that name isn't the same as the
> name of the parameter—one's a preposition, the other's a noun. I'm
> pretty sure the common case is still unlabeled. Does that justify the
> complexity of the current rule?
>
> (But because Objective-C methods will now often have labeled
> arguments, it would at least no longer be a marker differentiating
> "pure Swift" code from "Cocoa" code.)
>
> Jordan
>
>
>> On Mar 9, 2016, at 14:32, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Looking at my code, the majority of methods should still have the
>> first parameter unlabeled.
>>
>> I like the consistency of what you’re proposing and the fact that I don’t have to write `func foo(someArgument someArgument: T)` anymore. But I also fear people won’t get it that they can (and in many, probably most, situations should) make the first parameter `_ foo`.
>>
>> — Radek
>>
>>> On 09 Mar 2016, at 19:58, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> Our accepted naming guidelines have embraced first argument labels for functions and methods. This weakens our justification for making the first parameter declaration in a `func` declaration behave differently from the others, implicitly being unlabeled. It seems pretty clear to me we should make all of the parameter declarations behave uniformly:
>>>
>>>> func foo(x: Int, y: Int) // Should declare foo(x:y:), instead of foo(_:y:)
>>>> func foo(_ x: Int, y: Int) // Explicitly declares foo(_:y:)
>>>>
>>> This would also make `init` and `func` parameters behave
>>> consistently, which is nice. There may still be hope for our keyword
>>> argument rules to one day be shorter than the Smalltalk spec…
>>>>
>>> -Joe
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _________________________________________________
> 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/20160310/07abeca6/attachment.html>