<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 Mar 9, 2016, at 5:24 PM, Rudolf Adamkovič via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">+1</div><div class=""><br class=""></div><div class="">P.S. During my Swift tutoring lessons, the current behavior confuses everybody to no end.</div></div></div></blockquote><div><br class=""></div>…are we sure this isn’t just because people are just down right daft at times. &nbsp;I would in no way consider the Swift 2 syntax confusing. &nbsp;It’s ugly (compared to the proposed 'func foo(x: Int, y: Int)') and frustrating to be sure, but not confusing. &nbsp;Like all students learning something, sometimes one just have to take something at face value—it is what it is and that’s life, haha. &nbsp;Sometimes I really find myself wondering if anyone has ever read “The Swift Programming Language” text. &nbsp;It always seems like people spend more time just “playing around" with Swift—learning by trial and error. &nbsp;That’s a bad idea for learning anything as experimenting and understanding what the result requires knowing something in the first place.</div><div><br class=""></div><div>No offense, but if people would spend more time learning the language instead of comparing it to other languages while they learn it, they may not have such problems. &nbsp;Perhaps even a good number of the arguments put forth on these threads may not come up either… food for thought.</div><div><br class=""></div><div>I’m definitely +1 on making ‘func' and and ‘init' have the same type of argument signature.</div><div><br class=""></div><div>&nbsp; &nbsp; func foo(x: Int, y: Int) // Looks so much BETTER!!!!</div><div><br class=""></div><div>Myles</div><div><br class=""></div><div><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="">R+</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 9 Mar 2016, at 19:58, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">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:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func foo(x: Int, y: Int) // Should declare foo(x:y:), instead of foo(_:y:)</div><div class="">func foo(_ x: Int, y: Int) // Explicitly declares foo(_:y:)</div><div class=""><br class=""></div></blockquote>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=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><br class=""></div></blockquote>-Joe</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>_______________________________________________<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>