Austin, I agree with your point here that any sort of label should be prohibited at the call site if your proposal is adopted; along those lines, your suggested alternative of disallowing them in the type annotation might win in terms of appropriately setting user expectations about labels despite the loss in documentation.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 30, 2016 at 13:44 Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is a good point. I feel like calling `x` with any sort of argument labels should be prohibited. I don&#39;t think there&#39;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 &quot;erased&quot;.<div><br></div><div>(There might be an alternate universe in which Swift&#39;s function types&#39; 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&#39;s probably better to just formalize the semantics as described above than vacillating on whether argument labels are significant or not.)</div></div><div dir="ltr"><div><br><div><br></div><div>Austin</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 30, 2016 at 11:37 AM, Sean Heber via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><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>
<br>
func doSomething(x: Int, y: Int) -&gt; Bool { return true }<br>
let x = doSomething<br>
x(10, 10)<br>
<br>
Is it then legal to do this?:<br>
<br>
x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10)<br>
<br>
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>
<br>
l8r<br>
Sean<br>
<span><br>
<br>
&gt; On Jun 30, 2016, at 1:26 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hello Swift community,<br>
&gt;<br>
&gt; The review of &quot;SE-0111: Remove type system significance of function argument labels&quot; begins now and runs through July 4. The proposal is available here:<br>
&gt;<br>
&gt;       <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a><br>
&gt;<br>
&gt; Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
&gt;<br>
&gt;       <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt; or, if you would like to keep your feedback private, directly to the review manager.<br>
&gt;<br>
&gt; What goes into a review?<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt;       * What is your evaluation of the proposal?<br>
&gt;       * Is the problem being addressed significant enough to warrant a change to Swift?<br>
&gt;       * Does this proposal fit well with the feel and direction of Swift?<br>
&gt;       * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
&gt;       * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
&gt;<br>
&gt; More information about the Swift evolution process is available at<br>
&gt;<br>
&gt;       <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt; -Chris Lattner<br>
&gt; Review Manager<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
</span>&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div>