<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 30, 2016, at 9:36 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a> ]</div><div class=""><br class=""></div><div class="">This is my feeling as well. Argument labels are definitely part of the <i class="">name</i> of the function, but they aren’t part of the <i class="">type</i>. A few functions happen to have argument labels </div><div class=""><br class=""></div><div class="">On future directions: I’m mildly in favor of allowing parameters and locals with closure type to have labels in the name: </div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func map<Result>(_ transform(from:): (Element) -> Result) -> [Result]</div><div class="">func map<Result>(_ transform: (from: Element) -> Result) -> [Result]</div></blockquote><div class=""><br class=""></div>which, yes, would require you to rewrite the names if you cared, but would at least <i class="">allow</i> you to rewrite the names if you cared. More importantly, it lets you document callbacks properly. (This kind of works by coincidence today.)</div></div></blockquote><div><br class=""></div><div>This *might* make sense. I almost included something similar in my review. It is one of the use cases I had in mind when I mentioned the possibility of designing a less fragile feature for specific uses cases. But that discussion is for the future. :)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I am in favor of this proposal.<br class=""><div class=""><br class=""></div><div class="">Jordan<br class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 30, 2016, at 11:44, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This is a good point. I feel like calling `x` with any sort of argument labels should be prohibited. I don't think there's any expressivity penalty for doing so (especially since tuple splat is gone); plus, once a function is reified as a value (as opposed to being invoked by naming it directly), I think the most principled thing to do is to consider the argument labels "erased".<div class=""><br class=""></div><div class="">(There might be an alternate universe in which Swift's function types' argument labels are *fully* significant by disallowing conversions between function values declared with different argument labels, but Swift has never actually enforced such a requirement, and so it's probably better to just formalize the semantics as described above than vacillating on whether argument labels are significant or not.)<br class=""><div class=""><br class=""></div><div class="">Austin</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 30, 2016 at 11:37 AM, Sean Heber via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This mostly makes sense to me and it seems like mostly a good idea, but take this example:<br class="">
<br class="">
func doSomething(x: Int, y: Int) -> Bool { return true }<br class="">
let x = doSomething<br class="">
x(10, 10)<br class="">
<br class="">
Is it then legal to do this?:<br class="">
<br class="">
x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10)<br class="">
<br class="">
That would seem odd to me. Maybe it could be useful, but it might also be *super* confusing. I’m not sure I have a suggestion as to what to do in a situation like this - but it doesn’t seem “right” to allow it.<br class="">
<br class="">
l8r<br class="">
Sean<br class="">
<span class=""><br class="">
<br class="">
> On Jun 30, 2016, at 1:26 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Hello Swift community,<br class="">
><br class="">
> 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:<br class="">
><br class="">
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a><br class="">
><br class="">
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br class="">
><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
><br class="">
> or, if you would like to keep your feedback private, directly to the review manager.<br class="">
><br class="">
> What goes into a review?<br class="">
><br class="">
> 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:<br class="">
><br class="">
> * What is your evaluation of the proposal?<br class="">
> * Is the problem being addressed significant enough to warrant a change to Swift?<br class="">
> * Does this proposal fit well with the feel and direction of Swift?<br class="">
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class="">
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class="">
><br class="">
> More information about the Swift evolution process is available at<br class="">
><br class="">
> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a><br class="">
><br class="">
> Thank you,<br class="">
><br class="">
> -Chris Lattner<br class="">
> Review Manager<br class="">
><br class="">
><br class="">
> _______________________________________________<br class="">
</span>> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>