<div dir="ltr"><div>How does this proposal agree with tuple labels? Compare:</div><div><br></div><div>func find(array: [Int], value: Int) -> (index: Int, value: Int)</div><div>let result = find(...)</div><div>result.index //=> 0</div><div><br></div><div>func getHandler(for kind: EventKind) -> (event: Event, parent: Widget) -> ()</div><div>let result = getHandler(...)</div><div>result(event: ..., parent: ...)</div><div><br></div><div>We are going to prohibit second without removing the first; how is that consistent?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-04 14:17 GMT+03:00 Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> * What is your evaluation of the proposal?<br>
<br>
I agree that the current situation is incoherent. If the type system doesn't care about the labels, the labels probably shouldn't be in the type.<br>
<br>
In the long run, it must be possible to label the parameters of a closure. But that labeling does not *necessarily* belong on the type; it could go on the name:<br>
<br>
// Old and busted<br>
let completion: (records: [Record]?, error: Error?) -> Void<br>
// New hotness<br>
let completion(records:error:): ([Record]?, Error?) -> Void<br>
<br>
And I don't think it would be terrible to remove the labels from the type before we add them to the name.<br>
<br>
On the other hand, we could go the other direction and make the labels significant. Or—to address the `remove(from:)`/`add(to:)` critique—we could perhaps make the *internal* names significant, while considering the internal labels as part of the variable name. (Presumably both `remove(from:)` and `add(to:)` would be of type `(collection: WidgetCollection) -> Void`.)<br>
<br>
Both options are sensible; the status quo is not. We should choose a direction and start going that way.<br>
<br>
> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
Yes. The type system is being a bit nonsensical here.<br>
<br>
> * Does this proposal fit well with the feel and direction of Swift?<br>
<br>
Yes. Swift 3, breaking everything now, etc.<br>
<br>
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
Can't really think of much that's comparable.<br>
<br>
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
Quick reading.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>