On Jun 29, 2015, at 15:42 , Rick Mann <rm...@latencyzero.com> wrote: > > Here's an example (and this is what I frequently encounter) where requiring > parameter names adds nothing but clutter: > > let config = WKWebViewConfiguration() > self.webView = WKWebView(frame: self.webViewContainer.frame, > configuration: config);
I’ve been thinking about this since yesterday, and while I don’t particularly agree that the parameter names are extraneous in *this* case, I can think of a couple of special cases: 1. If the function/method being called has extremely well-known parameters, then I think I’d prefer the function to have a form that omits the names. In particular, CGRect, CGPoint and CGSize: > let rect = CGRect (x: 0, y: 0, width: 10, height: 10) // vs: > let rect = CGRect (0, 0, 10, 10) The point here is that the parameter semantics are known from the *name* of the function, not from the actual parameters. We have this convention already, in the default behavior where the first keyword to a regular function/method is omitted: > doSomethingWithRect (someRect) This is similar to the CGRect initializer case, in that we know from the name what the parameter is (because it tells us, in this case, not necessarily because we knew it in advance). 2. There’s common situation where a variable name very often *is* a parameter keyword. For example: > init (frame: CGRect, configuration: WKWebViewConfiguration) { > super.init (frame: frame, configuration: configuration) > } In this case, the name of the variable in the ‘super’ call *is* the same as the keyword, because that’s a syntactic default in Swift. Under these circumstances, I could see this being allowed: > init (frame: CGRect, configuration: WKWebViewConfiguration) { > super.init (frame, configuration) > } It may or may not be desirable to require that the keywords are all omitted or all retained, or that this would only work for parameter variables (which have a natural relationship to their keyword). What do you think? This wouldn’t eliminate all the cases you’ve set your sights on, but it would probably remove the most egregious ones. If there’s some consensus here, I’ll file radars. _______________________________________________ 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