[swift-evolution] Property Getter Return Statement

[Mike Kluev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171011/8e215562/attachment.html>