<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 Apr 15, 2016, at 11:27 AM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</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="">Hmm... I don't think this is clearer:<div class=""><br class=""></div><div class=""><font face="Menlo" class=""> let fn: (Int) -> (Int) -> Int</font></div><div class=""><br class=""></div><div class="">I think it's much less readable and really, the () are syntactically redundant: the -> is really what distinguishes this as a function.</div><div class=""><br class=""></div><div class="">Also, this would look like a error now:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> let fn: (Int) -> ()</font></div></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">Did the user mean that it returns nothing, or did they forget the rest of the function signature?</div></div></div></blockquote><div><br class=""></div><div>Hi David,</div><div><br class=""></div><div>I’m not sure what you’re saying here. The two types above are already valid, and this proposal doesn’t affect that.</div><div><br class=""></div><div>-Chris</div><br class=""><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=""><br class=""></div><div class="">I'd like to see more consistency and less redundancy, including special cases, in the language in general, but this change just seems to make it different in another way, but still not consistent throughout the language constructs.</div><div class=""><br class=""></div><div class="">-David</div><div class=""><br class=""></div><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2016, at 9:57 PM, Chris Lattner 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=""><div class="">We currently accept function type syntax without parentheses, like:<br class=""><br class=""> Int -> Float<br class=""> String -> ()<br class=""><br class="">etc. The original rationale aligned with the fact that we wanted to treat all functions as taking a single parameter (which was often of tuple type) and producing a tuple value (which was sometimes a tuple, in the case of void and multiple return values). However, we’ve long since moved on from that early design point: there are a number of things that you can only do in a parameter list now (varargs, default args, etc), implicit tuple splat has been removed, and the compiler has long ago stopped modeling function parameters this way. Beyond that, it eliminates one potential style war.<br class=""><br class="">Given all this, I think it makes sense to go for syntactic uniformity between parameter list and function types, and just require parenthesis on the argument list. The types above can be trivially written as:<br class=""><br class=""> (Int) -> Float<br class=""> (String) -> ()<br class=""><br class="">Thoughts?<br class=""><br class="">-Chris<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>