SE-0255: Implicit Returns from Single-Expression Functions

This doesn’t work. The top var in your example is already valid syntax and is a stored property. I discussed this direction upthread. It would require new syntax. I used := as a strawman.

I generally don’t think this direction is a good idea unless we are willing to consider return type inference when the := shorthand is used to declare a function. I can’t think of any good reason why we would allow return type inference for a computed property but not for a function.

If we aren’t going to support return type inference (we probably aren’t) then I think this proposal is the best and most consistent direction. Using braces only requires one additional character over the = syntax and zero additional characters over the := syntax. It is also consistent with Swift’s current design that all code bodies appear inside braces (with the single exception of direct initialization of stored properties).

This syntax could work for functions, but not for properties which already use the = operator:

// Already looks for an available `reduce` method in the current scope
var sum = reduce(0, +)

A possible solution would be to use the := operator, which is already used in several languages as a definition operator, and is not yet used in Swift:

func sum() -> Int := reduce(0, +)
var sum := reduce(0, +)

I also think that this syntax could address several concerns of @svanimpe above. Do you think it would help students understand that reduce returns a value despite its imperative form?

• What is your evaluation of the proposal?

+1

Implicit returns from single-expression functions and properties seems like a natural extension of Swift, and matches implicit returns from single-expression closures.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes

• Does this proposal fit well with the feel and direction of Swift?

Yes. The parallel with single-expression closures seems elegant and Swifty to me.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal and followed the discussion.

Jeremy

Hmm. This might be too much type omission.

The type inference system depends on having type information at the point where functions and properties are declared. Routinely omitting that information would make the system work much harder and slower, and lead to more frequent unsolvable cases.

Also, in practice, this might be harder to read at a glance if not used judiciously.

2 Likes

So, now, I am way off topic. Apologies to everyone. A couple of quick thoughts, and then I will refrain.

  • Consistent Syntax: I think the operator (if any) and right-hand sides for functions and computed properties need to use the same syntax. This suggestion accomplishes that objective.

  • Syntax for Type of Computed Property: I'm not sure of the explicit type syntax for the computed property. Would it be var sum: Int := reduce(0, +)?

  • Preference: I don't know whether users would prefer this approach over that championed by the proposal at hand. Do we need data? How does one obtain such data?

  • Consistency of Braces: Omitting the braces in these instances isn't great. It feels like the language would be heading down a path of having a mish-mosh of syntax. Would it be better to use the plain = operator, and keep the braces on the right side? Such as:

func sum() -> Int = { reduce(0, +) }
var sum: Int = { reduce(0, +) }    

Do you disagree with the use of implicit returns in closures, and do you think that's comparable to this?

Good point.

I’m not convinced that adding = would serve any meaningful purpose over the proposed syntax.

This:

func sum() -> Int = { reduce(0, +) }

vs:

func sum() -> Int { reduce(0, +) }

1 Like

My apologies. It was just an exploration of Chris Lattner's suggestion for an alternative syntax. And clearly this is not what is proposed in SE-0255. We can just leave that here.

I think closures are a different story.

collection.filter { $0.age >= 18 }.map { $0.name }

With closures, you tend to think only about the expression. In the example above, you're filtering based on a condition and mapping to a value. You're not really thinking about declaring a function that returns a value; that's just an implementation detail.

My experiences with closures are that:

  • students with prior programming experience tend to struggle with the syntax in general because they've only used arrow syntax so far (e.g. in Java or C#).
  • students learning Swift as their first language have less issues with the syntax because they have no preconceptions as to what closures should look like. They tend to struggle mostly with trailing closures. I've seen a lot of these students avoid trailing closures at first and only adopt them when they have a better understand of closures in general.
2 Likes

Proposal Accepted

The review demonstrated clear support for this syntax for property and subscript getters, where the need to return simple single expressions is common.

On eliding the return from functions, the review feedback was more divided. While there was support from some reviewers, others expressed the view that the feature should be restricted to just getters. However, on reviewing the feedback, the core team does not see a strong case was made against applying it to functions as well, when weighed against the benefits of a single uniform rule.

Some reviewers floated the idea of a different syntax for function declaration, using = or => , as seen in other languages. The core team doesn't feel this syntax handles properties or subscripts well, and does not consider sugaring function declarations specifically with a separate syntax a useful change.

The core team also acknowledges that accepting this feature may encourage follow-on proposals that generalize it further, such as converting if/ switch statements into expressions, or allowing elision in multi-statement bodies. Accepting this proposal doesn't necessarily endorse or rule out those future directions.

Thank you to everyone who participated in this review!

Ben Cohen
Review Manager

23 Likes