[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Brad Hilton brad.hilton.nw at gmail.com
Fri Jul 1 09:37:05 CDT 2016


> What is your evaluation of the proposal?

-1. Argument labels can have meaning and are very useful, especially for default parameter names in closures:

```// Declaration
func handleResponse(handler: (response: Response) -> ())

// Callsite
handleResponse { response in // response automatically implied as the parameter name, clarifying usage.
  ...
}
```

I’d prefer we leave the existing behavior or consider the alternative solution to prohibit implicit subtyping.

>Does this proposal fit well with the feel and direction of Swift?

I don’t feel that it does. I’ve always felt that being able to declare function types with named parameters was a powerful feature that allowed more expressivity in the language.

``` // Clear that the first String argument is the message and that the second is the sender
let messageHandler: (message: String, sender: String) -> ()

// Not clear what these parameters are
let messageHandler: (String, String) -> ()```

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The closest comparison I can think of are Objective-C selectors, but these are more powerful and type-safe. I think it’s a real strength of the language.

> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading, and I have used function declarations with and without labels extensively.

> Hello Swift community,
> 
> The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 

> * Is the problem being addressed significant enough to warrant a change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> 
> 


More information about the swift-evolution mailing list