> 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
> 
> 
> 
> 
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to