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

Félix Cloutier felixcca at yahoo.ca
Wed Mar 9 15:01:58 CST 2016


I actually thought that this change was implied with the new guidelines.

Félix

> Le 9 mars 2016 à 15:35:12, Tanner Nelson via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I would agree that in following the Swift.org <http://swift.org/> API Design Guidelines I've had to do a lot of `func foo(x x: Type)`.
> 
> But simple functions like `.remove(element)` or `.append(element)` that really don't need labels are ubiquitous and would need to be changed to `_ x:`. 
> 
> I assume the goal is to have the default case be whatever developers will use most commonly. 
> 
>> On Mar 9, 2016, at 3:15 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> +1 Yes
>> 
>> the current solution makes me wish we still have the # from swift 1 ;)
>> 
>> 	func foo(x x: Int, y: Int) // Swift 2
>> 	func foo(#x: Int, y: Int) // Swift 1
>> 
>> 
>>> On Mar 9, 2016, at 10:58 AM, 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

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


More information about the swift-evolution mailing list