On Tue Oct 10 15:02:37 CDT 2017 Slava Pestov spestov at apple.com wrote:
>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
