> On Jun 24, 2015, at 14:53 , Greg Parker <gpar...@apple.com> wrote: > > 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.
I guess I disagree with this assertion. Generally, in a given body of code, the usage will be consistent, and of course there are the billions of lines of existing (C) code where no parameter names are specified. > 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.) Again, this allows the author of the function to dictate, but not the caller. We call many more functions than we write, so this increases the burden. The default naming rule is clearly a holdover from Objective-C, and really seems to make little sense. If part of the argument is "most functions have only one parameter," then I'd say the rule should be based on number of parameters, not first-vs-rest. I strikes me as terribly inconsistent as it is, and terribly burdensome. I *rarely* find improvement to naming the parameters at the call site. Maybe I'm just better at naming the variables I pass as arguments. > On Jun 24, 2015, at 14:42 , Jens Alfke <j...@mooseyard.com> wrote: > > There isn’t always enough information, when there are optional parameters. > Without keywords it can be ambiguous which parameters have been omitted. > > Also, can’t functions be overloaded by using different parameter names, the > way methods can? Which is why I was careful to state "If there's enough information available…." Obviously if there is not (given the arguments and their types supplied), then specifying one or more parameter names would be a fine way to discriminate. But to ALWAYS require them is IMO not necessary. Why is it considered okay to infer types? Wouldn't it be more clear if you had to specify types? I don't see this discussion as substantially different. One possibility I raised in the Radar bug I filed was to make it an option that can be passed to the compiler. If the call can be unambiguously discriminated without parameter names, then the option would allow them to be omitted. -- Rick Mann rm...@latencyzero.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
