<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 <<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="">+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. I would in no way consider the Swift 2 syntax confusing. It’s ugly (compared to the proposed 'func foo(x: Int, y: Int)') and frustrating to be sure, but not confusing. 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. Sometimes I really find myself wondering if anyone has ever read “The Swift Programming Language” text. It always seems like people spend more time just “playing around" with Swift—learning by trial and error. 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. 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> 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 <<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="">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>