# SE-0255: Implicit Returns from Single-Expression Functions

**URL:** <https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544>\
**Category:** Proposal Reviews\
**Created:** [April 2, 2019, 8:26pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544 "2019-04-02T20:26:32Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\
**Post date:** [April 4, 2019, 8:39am UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/42 "2019-04-04T08:39:11Z")

</div>

> [@Chris\_Lattner3](#):
>
> wouldn't it make sense to either apply the [exceptions](https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md#exceptions) to closures as well

We already apply these exceptions to closures (though the mechanism might be slightly different). That's why these closures typecheck:

```swift
func f(_: () -> Void) {}
f { "f was called" }
func g(_: () -> Int) {}
g { fatalError() }

```

---

<div class="post-metadata">

**Author:** ![Jon\_Hull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_hull/32/678_2.png) [@Jon\_Hull](https://forums.swift.org/u/Jon_Hull)\
**Post date:** [April 4, 2019, 8:55am UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/43 "2019-04-04T08:55:23Z")

</div>

I'm torn on this.

I do constantly write single line getters (and often single line operators too) without the return, and then I have to go back and add it in, so I guess my brain thinks Swift should work this way.

On the other hand, I don't think it makes sense for init (the only use I can think of is `init?(){nil}`). I am also not sure that we should treat something with get/set blocks as "single line".

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [April 4, 2019, 8:58am UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/44 "2019-04-04T08:58:46Z")

</div>

Fair, my brain likes being explicit and thinks that inferring (well “ **implying** ” actually :)) is the mother of potential misunderstanding at some point in day to day conversations and in tech projects too... I feel like putting return everywhere where the code... returns :).

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [April 4, 2019, 1:51pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/46 "2019-04-04T13:51:14Z")

</div>

> [@Panajev](#):
>
> Fair, my brain likes being explicit and thinks that inferring (well “ **implying** ” actually :)) is the mother of potential misunderstanding at some point in day to day conversations and in tech projects too... I feel like putting return everywhere where the code... returns :).

We should be very clear: nothing in this proposal will stop you from doing that, or even using a linter that will _force_ all code in a project to do so. The proposal only relaxes the requirement that **all** Swift code must be written this way.

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [April 4, 2019, 3:47pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/47 "2019-04-04T15:47:56Z")

</div>

Eh. I'm in favor of the proposal, but if all code is not written a certain way, your brain doesn't get to rely on it. (That's why I've been consistently against compilation-wide warning flags.)

---

<div class="post-metadata">

**Author:** ![mos42](https://avatars.discourse-cdn.com/v4/letter/m/ed655f/32.png) [@mos42](https://forums.swift.org/u/mos42)\
**Post date:** [April 4, 2019, 4:08pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/48 "2019-04-04T16:08:30Z")

</div>

> [@mattrips](#):
>
> I'm on safe ground asserting that, for many users, there is little or no distinction between a single-expression closure, function or getter.

I am one of them.

> [@Panajev](#):
>
> Fair, my brain likes being explicit and thinks that inferring (well “ **implying** ” actually :)) is the mother of potential misunderstanding at some point in day to day conversations and in tech projects too... I feel like putting return everywhere where the code... returns :).

I can relate. Back in the day I would even ensure all my property declarations are type annotated. This was until I started using Playgrounds on a daily basis to explore different ways to approach a problem (I mostly write and support internal tools / frameworks) - it’s here that I realized how much I liked the small things the compiler does for me (type inference, implicit return from closures, etc). Changed my mind.

> [@mattrips](#):
>
> To answer the last bit of your challenge (“… need to be unified, but others shouldn’t”), this proposal is scoped as it is. The authors are not speaking to any other inconsistencies, existing or future. Certainly, it would be unfair to ask that they address the state of consistency across the rest of the language, and the success of this proposal should not hinge on the same.

I would also like to add my voice to what Matt said above.

---

<div class="post-metadata">

**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\
**Post date:** [April 4, 2019, 5:06pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/49 "2019-04-04T17:06:51Z")

</div>

> [@jrose](#):
>
> but if all code is not written a certain way, your brain doesn't get to rely on it.

I share that sentiment. At the end of the day, this sort of choice is about stylistic preference and the exercise of good judgment.

I wonder how linters and style guides currently handle, and going forward would handle, the decision to use or not use an explicit `return` in a single-expression closure/function/accessor. Ugh. I want to bang my head on my desk and reconsider whether the proposal is a good idea.

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [April 4, 2019, 5:18pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/50 "2019-04-04T17:18:04Z")

</div>

(posting in personal capacity, not as review manager)

> [@Chris\_Lattner3](#):
>
> The primary argument for this seems to be consistency with closure syntax.

I think this is a mischaracterization. The proposal itself does not make this its primary argument, instead opening with the case that `return` takes up disproportionate space in simple function declarations. And the strongest support on this review thread and elsewhere seems to come from the improvement it brings to both reading and writing computed properties.

Consistency is certainly a secondary argument though. The proposal suggests eliding the return on functions will "help prepare new Swift users to understand" closures, which I think is a reasonable point. [Elsewhere](https://forums.swift.org/t/se-0253-static-callables/22243/32) I've suggested that the consistency with closures makes this proposal an easier bit of sugar to accept, because that consistency means the sugar arguably _lowers_ the complexity of the language, unlike other sugar that relies on adding new features to the language.

There's some pushback here to applying this change to functions even if we accept it for getters and subscripts. My personal opinion is it would be OK to not do it for functions, but the consistency of applying the same rule across the board means its worth doing and outweighs the reasons to not.

I find the choice between closures and functions to be a lot blurrier than others seem to. For example, suppose you find yourself writing

```swift
numbers.map { $0*2 }

```

Maybe for readability or because you are using this closure in a couple of different places, so you give it a name:

```swift
let double = { $0*2 }
numbers.map(double)

```

But then it turns out you're using it on not-integers, so you have to give it some type context:

```swift
let double = { i -> Double in i*2 }

```

At this point you're getting close to "may as well make it a function" territory:

```swift
func double(_ i: Double) -> Double { return i*2 }

```

To push it over the edge, you might want to make it generic, which would have to be a function:

```swift
func double<T: Numeric>(_ i: T) -> T { return i*2 }

```

At what seems like an arbitrary point in this otherwise smooth transition up the ladder of expressivity, you are forced to introduce a `return`. Why? Seems arbitrary to me. Not a big deal, maybe, but this is somewhere the consistency would make the language better IMO, by smoothing transition between these two forms. So while I'm strongly in favor of this proposal for the purpose of getters, I'm also in favor of it applying across the board.

---

<div class="post-metadata">

**Author:** ![mos42](https://avatars.discourse-cdn.com/v4/letter/m/ed655f/32.png) [@mos42](https://forums.swift.org/u/mos42)\
**Post date:** [April 4, 2019, 5:31pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/51 "2019-04-04T17:31:33Z")

</div>

> [@mattrips](#):
>
> I wonder how linters and style guides currently handle, and going forward would handle, the decision to use or not use an explicit return in a single-expression closure/function/accessor.

When it comes to SwiftLint today, `- implicit_return` rule is disabled by default.

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [April 4, 2019, 5:33pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/52 "2019-04-04T17:33:13Z")

</div>

> [@anandabits](#):
>
> We should be very clear: nothing in this proposal will stop you from doing that, or even using a linter that will _force_ all code in a project to do so.

That's true for any additive change, but:

> [@jrose](#):
>
> but if all code is not written a certain way, your brain doesn't get to rely on it.

That's my problem with the proposal. I see in my (anecdotal) experience that most single-line closure omits `return`, but I can see non-trivial amount of those who will adopt the proposal, as well as those who will refuse to do so, so it'll put some strain on the reader anyway. The _consistency_ and _ease of parsing_ arguments are quite weak for the stylistic difference it'll introduce.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [April 4, 2019, 5:42pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/53 "2019-04-04T17:42:31Z")

</div>

> [@Lantua](#):
>
> That's my problem with the proposal. I see in my (anecdotal) experience that most single-line closure omits `return` , but I can see non-trivial amount of those who will adopt the proposal, as well as those who will refuse to do so, so it'll put some strain on the reader anyway. The _consistency_ and _ease of parsing_ arguments are quite weak for the stylistic difference it'll introduce.

This argument goes back to the style guidelines holy war. As we have seen, there are a wide range of opinions on that topic.

Personally, I don’t care about consistency from one codebase to another, especially across organizations. Linters will make it easy enough to maintain stylistic consistency _within_ a codebase if the authors desire that and need a tool to accomplish it.

---

<div class="post-metadata">

**Author:** ![Lily\_Ballard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lily_ballard/32/5050_2.png) [@Lily\_Ballard](https://forums.swift.org/u/Lily_Ballard)\
**Post date:** [April 4, 2019, 5:49pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/54 "2019-04-04T17:49:29Z")

</div>

> [@jrose](#):
>
> I'm coming around to Rob and Nevin's (slightly different but both good) views on this. I want this _all the time_ for property and subscript getters, but don't really care for functions, and think keeping the return makes a function minorly easier to read.

I agree with this, though I'd go even further and say I explicitly don't want this for functions. Getters yes, functions no.

---

<div class="post-metadata">

**Author:** ![mos42](https://avatars.discourse-cdn.com/v4/letter/m/ed655f/32.png) [@mos42](https://forums.swift.org/u/mos42)\
**Post date:** [April 4, 2019, 5:57pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/55 "2019-04-04T17:57:11Z")

</div>

> [@Lantua](#):
>
> That's my problem with the proposal. I see in my (anecdotal) experience that most single-line closure omits `return` , but I can see non-trivial amount of those who will adopt the proposal, as well as those who will refuse to do so, so it'll put some strain on the reader anyway. The _consistency_ and _ease of parsing_ arguments are quite weak for the stylistic difference it'll introduce.

One way we can ensure _ease of parsing_ is by having a common set of rules enforced by the linter.

Being _able_ to implicitly return from functions or getters is not the same as _enforcing_ the rule.

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [April 4, 2019, 6:04pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/56 "2019-04-04T18:04:34Z")

</div>

Thanks for the thorough reply, @mattrips.

> [@mattrips](#):
>
> To answer the last bit of your challenge ("... need to be unified, but others shouldn't"), this proposal is scoped as it is. The authors are not speaking to any other inconsistencies, existing or future. Certainly, it would be unfair to ask that they address the state of consistency across the rest of the language, and the success of this proposal should not hinge on the same.

My point here wasn't _really_ to ask the proposal authors to expand the scope of this proposal, but to encourage proponents to think about why we have closure syntax that is distinct from function syntax at all. To reiterate with a (tongue-in-cheek) question that I posed in the pitch thread:

> [@](#):
>
> why not eliminate `func` entirely and declare all functions as `let foo = { (x: Int, y: Int) in x + y }` ?

I think that most (all?) people here would agree that there are benefits to at least some of the differences between closure and function syntax, and I think considering why _those_ "inconsistencies" are valuable but the single expression -\> implicit `return` inconsistency is not.

FWIW, I don't agree that this helps readability (except possibly in the case of read-only computed properties and subscripts). That closures are expressions means that they are used inline in other expressions, and point-of-definition is (usually) also point-of-use. Inserting `return`s in the middle of an expression like `numbers.filter { $0 > 5 } .map { $0 * 10 }` breaks the conceptual flow of the expression as a whole in a way that simply doesn't apply to function declarations.

> [@ben-cohen](#):
>
> At what seems like an arbitrary point in this otherwise smooth transition up the ladder of expressivity, you are forced to introduce a `return` . Why?

In light of my previous point, if we could go back and redesign the closure syntax from the beginning, I would advocate for requiring this change from step 1 to step 2, so that

```swift
numbers.map { $0*2 }

```

would be perfectly valid, but pulling the closure into its own variable would have to be written as:

```swift
let double = { return $0*2 }
numbers.map(double)

```

IMO, this would make the implicit `return` boundary non-arbitrary ("inline function-like things consisting of a single expression can omit the return, while function-like things used as decl initializers must be explicit"). However, given that this is not the state of Swift today, I'm not convinced the answer is to remove the boundary altogether and allow implicit `return`s everywhere.

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [April 4, 2019, 6:15pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/57 "2019-04-04T18:15:56Z")

</div>

> [@ben-cohen](#):
>
> ```swift
> let double = { i -> Double in i*2 }
> 
> ```
> 
> At this point you're getting close to "may as well make it a function" territory:

IMO that's where closure starts to get silly, one of the more powerful _feature_ of closure is that its type, and arguments are heavily inferred from context, which is a clear benefits over other declarations/expressions at use point.

> [@anandabits](#):
>
> Personally, I don’t care about consistency from one codebase to another

We do agree on that, my point is that the _consistency_ argument is quite weak to start another holy war. Though as @ben-cohen point out, that's more of a secondary argument.

---

<div class="post-metadata">

**Author:** ![spadafiva](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/spadafiva/32/6635_2.png) [@spadafiva](https://forums.swift.org/u/spadafiva)\
**Post date:** [April 4, 2019, 6:19pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/58 "2019-04-04T18:19:57Z")

</div>

> [@Jumhyn](#):
>
> FWIW, I don't agree that this helps readability (except possibly in the case of read-only computed properties and subscripts). That closures are expressions means that they are used inline in other expressions, and point-of-definition is (usually) also point-of-use. Inserting `return` s in the middle of an expression like `numbers.filter { $0 > 5 } .map { $0 * 10 }` breaks the conceptual flow of the expression as a whole in a way that simply doesn't apply to function declarations.

This is exactly how I feel about it. I've come around on being okay with this for 1 line computed variables, but still pretty strongly against remove `return` from any function declarations.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [April 4, 2019, 6:22pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/59 "2019-04-04T18:22:02Z")

</div>

> [@Lantua](#):
>
> my point is that the _consistency_ argument is quite weak

Consistency of the _language_ and consistency of _style_ are two completely different matters. The argument is based on consistency of the _language_. I think you're concerned about the consequences on consistency of _style_. That's legitimate to point out but it does not weaken the argument in favor of improving consistency in the _language_.

---

<div class="post-metadata">

**Author:** ![Avi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/avi/32/2962_2.png) [@Avi](https://forums.swift.org/u/Avi)\
**Post date:** [April 4, 2019, 6:48pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/60 "2019-04-04T18:48:20Z")

</div>

> [@Jumhyn](#):
>
> IMO, this would make the implicit `return` boundary non-arbitrary ("inline function-like things consisting of a single expression can omit the return, while function-like things used as decl initializers must be explicit").

For all the users of Swift that aren't compiler writers, that would seem extremely arbitrary. At least the current rules apply to different constructs -- functions are not closures, syntactically. Getters _do_ look a lot like closures, though, which is why I think there's overall less opposition to relaxing the rules there.

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [April 4, 2019, 6:54pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/61 "2019-04-04T18:54:41Z")

</div>

> [@Avi](#):
>
> For all the users of Swift that aren't compiler writers, that would seem extremely arbitrary.

The precise wording that I used in my phrasing, perhaps, but I don't think the conceptual difference between "closure/function that has a name" and "closure/function that does not have a name" is very difficult to understand even for non-compiler minded users of the language.

---

<div class="post-metadata">

**Author:** ![Avi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/avi/32/2962_2.png) [@Avi](https://forums.swift.org/u/Avi)\
**Post date:** [April 4, 2019, 6:58pm UTC](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544/62 "2019-04-04T18:58:54Z")

</div>

That's still more arbitrary than the current rules.

That would mean

```
let x = { y * 3 }()

```

would be valid, but breaks as soon as you change it to

```
let x3 = { y * 3 }
let x = x3()

```

It's the exact same body, it's still a closure, but because it's not being called at the point of declaration, it now needs a `return` keyword. That's arbitrary.

[edit]

I think, in general, that syntax should not change based on _how_ or _when_ something is used. Either one-line closures require an explicit `return`, or they don't.

[Previous page](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544.md?page=2)

[Next page](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544.md?page=4)