<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="">I’ve been thinking about this proposal, and don’t like it. I feel that it makes the language uglier, even if more consistent, and for a very common case.<div class=""><br class=""></div><div class="">But I do have one idea, which is to substitute a dot for the colon in the definition when no label is desired:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(x: Int, y: Int)<span class="Apple-tab-span" style="white-space:pre"> </span>// x is labeled</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(x. Int, y: Int)<span class="Apple-tab-span" style="white-space:pre"> </span>// x is unlabeled</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(x. Int, y. Int)<span class="Apple-tab-span" style="white-space:pre"> </span>// x and y are both unlabeled</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(xx x. Int)<span class="Apple-tab-span" style="white-space:pre"> </span>// Illegal to label a parameter when using the “.” shortcut</div><div class=""><br class=""></div><div class="">This makes things consistent, and even sortof pretty. It also has a bit of a shorthand, since you’re leaving out one dot of the colon to make it silent (unlabeled). I have no idea how much his might mess up the rest of the grammar, but it seems like it might work.</div><div class=""><br class=""></div><div class="">James<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 10, 2016, at 2:21 PM, Kevin Ballard 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="">
<title class=""></title>
<div class=""><div class="">This is a valid concern.<br class=""></div>
<div class=""> <br class=""></div>
<div class="">If we assumed that 50% of methods would have a labelled first parameter, and 50% would leave them unlabelled, and furthermore we assume that all methods with labelled first parameters would use the parameter name as the label, then I would support this proposal purely on the grounds that it's easier to write `func foo(_ bar: T)` than it is to write `func foo(bar bar: T)`.<br class=""></div>
<div class=""> <br class=""></div>
<div class="">However, if we assume that the majority of methods still want an unlabelled first parameter (which seems like a reasonable assumption to me; most of the methods I write would certainly have the first parameter unlabelled), and similarly if we assume that a non-trivial amount of labelled first parameters use a different label than the parameter name, then this change doesn't make as much sense anymore.<br class=""></div>
<div class=""> <br class=""></div>
<div class="">Another concern with this proposal is that, even if you assume most methods with multiple parameters would want to label all the parameters, it's likely that most methods with a single parameter will leave the parameter unlabelled. But this proposed rule would cause even single-argument methods to label the sole argument.<br class=""></div>
<div class=""> <br class=""></div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""> <br class=""></div>
<div class="">On Wed, Mar 9, 2016, at 05:03 PM, Jordan Rose via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">This is my concern too. Our guidelines often lead to the first parameter having a label, but usually that name isn't the same as the name of the parameter—one's a preposition, the other's a noun. I'm pretty sure the common case is still unlabeled. Does that justify the complexity of the current rule?<br class=""></div>
<div class=""> <br class=""></div>
<div class="">(But because Objective-C methods will now often have labeled arguments, it would at least no longer be a marker differentiating "pure Swift" code from "Cocoa" code.)<br class=""></div>
<div class=""> <br class=""></div>
<div class="">Jordan<br class=""></div>
<div class=""> <br class=""></div>
<div class=""> <br class=""></div>
<div class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 14:32, Radosław Pietruszewski via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""> <br class=""></div>
<div class=""><div style="word-wrap:break-word;-webkit-line-break:after-white-space;" class=""><div class="">Looking at my code, the majority of methods should still have the first parameter unlabeled. <br class=""></div>
<div class=""> <br class=""></div>
<div class="">I like the consistency of what you’re proposing and the fact that I don’t have to write `func foo(someArgument someArgument: T)` anymore. But I also fear people won’t get it that they can (and in many, probably most, situations should) make the first parameter `_ foo`.<br class=""></div>
<div class=""> <br class=""></div>
<div class=""><div class="">— Radek<br class=""></div>
</div>
<div class=""> <br class=""></div>
<div class=""><blockquote type="cite" class=""><div class="">On 09 Mar 2016, at 19:58, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""> <br class=""></div>
<div class=""><div style="word-wrap:break-word;-webkit-line-break:after-white-space;" class=""><div class="">Our accepted naming guidelines have embraced first argument labels for functions and methods. This weakens our justification for making the first parameter declaration in a `func` declaration behave differently from the others, implicitly being unlabeled. It seems pretty clear to me we should make all of the parameter declarations behave uniformly:<br class=""></div>
<div class=""> <br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:40px;border-top-style:none;border-right-style:none;border-bottom-style:none;border-left-style:none;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-left-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:initial;border-image-source:initial;border-image-slice:initial;border-image-width:initial;border-image-outset:initial;border-image-repeat:initial;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;" class=""><div class="">func foo(x: Int, y: Int) // Should declare foo(x:y:), instead of foo(_:y:)<br class=""></div>
<div class="">func foo(_ x: Int, y: Int) // Explicitly declares foo(_:y:)<br class=""></div>
<div class=""> <br class=""></div>
</blockquote><div class="">This would also make `init` and `func` parameters behave consistently, which is nice. There may still be hope for our keyword argument rules to one day be shorter than the Smalltalk spec…<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:40px;border-top-style:none;border-right-style:none;border-bottom-style:none;border-left-style:none;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-left-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:initial;border-image-source:initial;border-image-slice:initial;border-image-width:initial;border-image-outset:initial;border-image-repeat:initial;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;" class=""><div class=""> <br class=""></div>
</blockquote><div class="">-Joe<br class=""></div>
</div>
<div class="">_______________________________________________<br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</blockquote></div>
<div class=""> <br class=""></div>
</div>
<div class="">_______________________________________________<br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</blockquote></div>
<div class=""> <br class=""></div>
<div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div 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 class=""> <br class=""></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=""></div></div></body></html>