Re: Swift and parameter names
Re: Swift and parameter names
- Subject: Re: Swift and parameter names
- From: Greg Parker <email@hidden>
- Date: Wed, 24 Jun 2015 14:53:32 -0700
> On Jun 24, 2015, at 2:09 PM, Rick Mann <email@hidden> wrote:
>
> I'm really liking Swift 2, and after watching some of the WWDC2015 videos on the subject, I can't wait to use it in a real project.
>
> But one area where it REALLY bugs me is that external parameter names are required. I can see their utility, particularly with regard to a set of default values and being able to specify just the ones you care about (I'm pretty sure this worked in a quick test I did).
>
> I'm less convinced that using external parameter names in function calls improves readability or clarity.
>
> But I don't understand the need to require the use of external names at the call site. If there's enough information available to the compiler at the call site to unambiguously choose a function or method to call, why must I supply the parameter names? Why not let the caller choose which external names to specify, and only emit an error when the result is ambiguous?
>
> It's all complicated by the fact that the first parameter doesn't need to have an external name, but the rest default to having one, and it's the function definer who decides if they're required.
>
> I'm going to write a bug about this, but it seems Swift 2 is more strict than than Swift 1.2 (as evidenced by the examples in the Language Guide), so I don't see Apple reversing course on this (even though I think it can be done with zero impact on existing Swift 2 code).
Swift 2 established a single default naming rule for all methods and global functions. Swift 1 had two different rules which was confusing. The naming rule (first parameter un-named, additional parameters named) was chosen because it is the best fit with Cocoa methods and most one-argument functions.
Swift's design is that the API author gets to choose what the call site looks like. Allowing the caller to choose whether to specify names or not hurts readability because of the inconsistency. It's bad for different calls to the same method to look too different.
If you as the author of a function think that the names are not useful, or conversely think that the first parameter should also be named, then you can write your function that way. Conversely, if you think the caller should be allowed to specify names or not then you can write two overloads, one of which simply calls the other. (I did something like this at one point for CGRect's initializers, allowing any of CGRect(1, 2, 3, 4) or CGRect(x:1, y:2, w:3, h:4) or CGRect(x:1, y:2, width:3, height:4). I don't remember if that arrangement survived.)
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden