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

James Berry jberry at rogueorbit.com
Thu Mar 10 17:14:59 CST 2016


I’ve been thinking about this proposal, and don’t like it. I feel that it makes the language uglier, even if more consistent, and for a very common case.

But I do have one idea, which is to substitute a dot for the colon in the definition when no label is desired:

	func foo(x: Int, y: Int)		// x is labeled
	func foo(x. Int, y: Int)		// x is unlabeled
	func foo(x. Int, y. Int)		// x and y are both unlabeled
	func foo(xx x. Int)			// Illegal to label a parameter when using the “.” shortcut

This makes things consistent, and even sortof pretty. It also has a bit of a shorthand, since you’re leaving out one dot of the colon to make it silent (unlabeled). I have no idea how much his might mess up the rest of the grammar, but it seems like it might work.

James



> On Mar 10, 2016, at 2:21 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>>  
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/f5cab834/attachment.html>


More information about the swift-evolution mailing list