<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=""><div class="">I didn’t see the pre-proposal, and I apologize if this has come up elsewhere on this list, but did you consider the alternative where you must use the compound name to refer to a function? That is:</div><div class=""><br class=""></div><div class="">func foo(a: A, b: B) -> C</div><div class="">func bar(from: A, using: B) -> C</div><div class="">let higherOrderABToC: (A, B) -> C = foo(a:b:)</div><div class="">higherOrderABToC = bar(from:using:)</div><div class=""><br class=""></div><div class="">That is, “foo” by itself is an incomplete name, and you must provide the full compound name. This will penalize convenience of references to functions, though you will simplify the overloading logic of functions: two functions are not overloaded if their full compound names differ. This can be thought of as taking SE0021 and running wild, enforcing that all naming of functions use the compound name.</div><div class=""><br class=""></div><div class="">The notion of providing the name of a function with a full compound name is increasingly common in Swift, with SE0021 generalized naming, improvements to swift_name, SE0044 import-as-member, etc.</div><div class=""><br class=""></div><div class="">To modify the example from later in the proposal:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">doSomething</span>(x: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>, y: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>) <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">-></span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Bool</span> {
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> x <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">==</span> y
}
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">somethingElse</span>(a: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>, b: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>) <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">-></span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Bool</span> {
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> a <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">></span> b
}
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// fn2's type is (Int, Int) -> Bool</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> fn2 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> doSomething(x:y:)
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Okay</span>
fn2(<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">1</span>, <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">2</span>)
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Okay</span>
fn2 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> somethingElse(a:b:)</pre><div class=""><br class=""></div></div><div class="">The notion here, is that we’re not just dropping argument labels from the type system, but instead we’re hoisting such concerns into the syntax by making them an intrinsic part of the name. Then, if you bind to it with a value, that value of course wouldn’t be called with labels because labels are not part of its name.</div><div class=""><br class=""></div><div class="">If this is unwieldy, then it’s worth stating how this behaves in the presence of functions overloaded based on argument label alone, as Erica mentions.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 30, 2016, at 3:43 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I would think that the naming guidelines are an argument for reducing the role of argument labels, if any.<div class=""><br class=""></div><div class="">This labeled tuple makes sense, because 'x' and 'y' describe the semantic meaning of each element (Int which represents an x-coordinate):</div><div class=""><br class=""></div><div class="">let myTuple: (x: Int, y: Int)</div><div class=""><br class=""></div><div class="">This also makes sense, because 'hits' and 'runs' describe the semantic meaning of each argument (Int which represents number of hits):</div><div class=""><br class=""></div><div class="">let a : (hits: Int, runs: Int) -> Bool</div><div class=""><br class=""></div><div class="">This makes absolutely no sense to me:</div><div class=""><br class=""></div><div class="">let b: (ofHits: Int, forRuns: Int) -> Bool</div><div class=""><br class=""></div><div class="">In fact, 'b' is a better example than the average, because of the naming guideline point to spell out the semantics of weakly typed arguments in the argument label.</div><div class=""><br class=""></div><div class="">func getWidget(for provider: Provider, with manifest: ShippingManifest) -> Widget { /* ... */ }<br class=""></div><div class=""><br class=""></div><div class="">let widgetGetter : (for: Provider, with: ShippingManifest) = getWidget</div><div class=""><br class=""></div><div class="">At this point, the labels are completely superfluous. They make no sense except in the context of a method name, because they are prepositional phrases. Knowing that the Provider is "for" something and something does something "with" the ShippingManifest is absolutely useless to anyone reading the code where the method name those labels are part of isn't immediately obvious.</div><div class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 30, 2016 at 3:33 PM, Michael Ilseman 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"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div class="">-1<br class=""><br class="">This proposal doesn’t even use Swift naming style to make its point, as soon as you do, the reason why Swift considers argument labels to be part of the type signature becomes apparent. <br class=""><br class="">The author of the proposal uses the following example:<br class=""><br class=""> func doSomething(x: Int, y: Int) -> Bool<br class=""><br class=""><br class="">This is just not Swift-y, a much better example would be:<br class=""><br class=""> func sinkBattleship(atX x: Int, y: Int) -> Bool<br class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class=""><pedanticism></div><div class="">If you want to talk about pedantic following of API naming guidelines for example code, then I believe that your example also runs afoul. It would be:</div><div class=""><br class=""></div><div class="">func sinkBattleshipAt(x: Int, y: Int) -> Bool</div><div class=""><br class=""></div><div class="">Due to a special case where the preposition covers multiple arguments. This arrises mostly from flatten-ed structs as parameters, e.g. from old C APIs predating struct literal syntax. See:</div><div class=""><br class=""></div><div class=""><ul style="margin:1em 0px;padding:0px 0px 0px 40px;list-style-position:initial;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,Verdana,sans-serif;font-size:18px" class=""><li style="margin:0px;padding:0px" class=""><div style="max-height:1000rem" class=""><p style="margin:0px 0px 1.5em;padding:0px" class="">An exception arises when the first two arguments represent parts of a single abstraction.</p><div class=""><pre style="margin:0.5em 0.5em 1.5em 10px;padding:0.5em 0.5em 0.5em 1em;font-size:14px;line-height:18px;border-left-width:3px;border-color:rgb(246,183,190);border-left-style:solid;overflow:visible;font-family:Menlo,Consolas,Monaco,'Courier New',monospace,serif;background-color:rgb(249,226,228)" class=""><code style="font-size:1em;white-space:inherit;font-family:Menlo,Consolas,Monaco,'Courier New',monospace,serif" class="">a.move(<strong class="">toX:</strong> b, <strong class="">y:</strong> c)
a.fade(<strong class="">fromRed:</strong> b, <strong class="">green:</strong> c, <strong class="">blue:</strong> d)
</code></pre></div><p style="margin:0px 0px 1.5em;padding:0px" class="">In such cases, begin the argument label <em class="">after</em> the preposition, to keep the abstraction clear.</p><div class=""><pre style="margin:0.5em 0.5em 1.5em 10px;padding:0.5em 0.5em 0.5em 1em;font-size:14px;line-height:18px;border-left-width:3px;border-color:rgb(192,255,188);border-left-style:solid;overflow:visible;font-family:Menlo,Consolas,Monaco,'Courier New',monospace,serif;background-color:rgb(230,255,229)" class=""><code style="font-size:1em;white-space:inherit;font-family:Menlo,Consolas,Monaco,'Courier New',monospace,serif" class="">a.moveTo(<strong class="">x:</strong> b, <strong class="">y:</strong> c)
a.fadeFrom(<strong class="">red:</strong> b, <strong class="">green:</strong> c, <strong class="">blue:</strong> d)
</code></pre></div></div></li></ul><div class=""><font color="#333333" face="Helvetica Neue, Helvetica, Arial, Verdana, sans-serif" size="4" class=""><br class=""></font></div></div><div class=""><div class=""></pedanticism></div><div class=""><br class=""></div></div><span class=""><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">the proposal states that the argument labels be then stripped from the type, which would make this method type-compatible with:<br class=""><br class=""> func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool<br class=""><br class=""><br class="">I don’t think it’s desirable for this to work at all… Argument labels are not parameter names, they are a first class part of Swift’s type system, and always meaningful when employed properly.<br class=""><br class=""><br class="">Scott<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></span></div><br class=""></div><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="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>