[swift-evolution] named parameters

Dave Abrahams dabrahams at apple.com
Fri Jan 22 17:36:36 CST 2016


on Fri Jan 22 2016, Tino Heth <swift-evolution at swift.org> 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?

I do. This kind of cruft adds up, and makes code much harder to read.
Also, FWIW, I would like calls to a given method to look the same in
most contexts.

-- 
-Dave



More information about the swift-evolution mailing list