I’m minorly opposed, because it feels like a slippery slope. What about
function bodies? etc
func foo() -> Int { 3 } // should this be allowed?
a small -1
or even:
func foo() { 3 } // Int return type inferred as well
a small -1
or
func(x = true) // Bool for x parameter inferred
a small +1
In fact the reason I thought the original thread was about
omitting the return type, rather than just omitting the ‘return’,
is that I feel the main reason that single-expression closures
exist is so that their type can be inferred as part of the
expression containing the closure. Swift does not infer types
across statement boundaries, so single expression closures
exist, as a special case, to help you avoid declaring types in some cases.
if you are from a school of thought that "everything is a closure" - it
would make sense.
"if expression closure else closure"
"var x { // return type inferred :-)
get closure
set closure
}"
"func foo closure"
in the latter case it would worth to use the same parameter passing syntax
as in closures for consistency:
func foo { (x: Int) in }
vs
func foo(x: Int) {}
Chris will say no, it’s about concision, and omitting the ‘return’,
but deep down in his heart, he knows that single-expression
closures were really just a type inference hack :-)
the amount of optimisation done in closure syntax was overwhelming when i
first saw it.
Mike
···
On Tue Oct 10 15:02:37 CDT 2017 Slava Pestov spestov at apple.com wrote: