[swift-evolution] named parameters

[Jordan Rose]

> On Jan 22, 2016, at 14:32, Tino Heth <2th at gmx.de> wrote:
> 
>>> UIView.insertSubview(_:,belowSubview:) and UIView.insertSubview(_:,aboveSubview:) beg to differ. As do UIView.convertPoint(_:,toView:) and UIView.convertPoint(_:,fromView:). Need more examples? Take a look at UITableViewDelegate.
>> 
>> Agreed. I'm quite happy that Swift labels are effectively part of the method name and therefore consistently applied. Long parameter lists are easy to get lost in.
> 
> That's exactly my opinion: Labels help us — the computer doesn't care weather a function has a meaningful name or is called as "f231(4, true)"
> Especially because of the benefit of labels, it's imho not necessary that the compiler enforces their use… but I think it's actually annoying to be forced to skip labels:
> 
> func printPowWithBase(base: Double, exponent: Double) {
> 	print(pow(base, exponent))
> }
> printPowWithBase(2, exponent: 3)
> 
> Easy to understand, works as expected — but would it hurt if
> 
> printPowWithBase(base: 2, exponent: 3)
> 
> would be accepted as well? Sure, "base:" is redundant, but who cares? And, as others already mentioned: For init, the first label is required…

If the library author decides to change the internal name, it's now a source-breaking change for clients. (Alternately, all the existing internal names are now external names, without any thought given to them, which would be just as bad.)


> Additionally, there is a hidden(?) feature in Swift that's imho quite cool:
> The ability to call a function with a tuple containing the arguments
> let args = (4.0, exponent: 4.0)
> printPowWithBase(args)
> 
> In this case, you end up with a first parameter without any indication of its role.

This feature is likely to get redesigned soon. (It has other problems.)

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