Request: Force return in functions or variables

[kimdv]

This is an opinionated rule, so it should be opt-in.

But a rule that enforces return.

Based in this discussion I think it could be a nice fit.

Triggers

func foo() -> String {
"bar"
}

func foo: String {
"bar"
}

Non-triggers

func foo() -> String {
return "bar"
}

func foo() -> Void {
someApiCall()
}

func foo() {
someApiCall()
}

func foo: String {
return "bar"
}

[allevato]

@xedin and I recently chatted about some new rules and an OmitReturns rule was one of those. Combined with this request, it probably makes sense to have a single opt-in rule that has two modes: always omit single-expr returns and never omit single-expr returns.

[Matejkob]

Would the "never omit single-expr returns" mode add missing return statements?

[allevato]

Yes, I would expect it to not just diagnose the code, but insert or remove return where applicable when run in format mode.

Trying to think of any edge cases where either of those operations would break...

[Matejkob]

This proposal could be quite a significant edge case.

[allevato]

Here's another one involving adding (or detecting the need for) return:

func f(closure: () -> Void) { closure() }
f { print("foo") }
// would become:
// f { return print("foo") }

That's still "correct" (semantically) but not likely to be desired. At the level of the f call, we can't tell that the closure isn't returning a value.

Result builders in general are another problem. There's no way to look at a closure or block syntactically and know that a result builder transform is being applied to it, so consider these two computed variables:

var body: some View {
  Text("blah")
}
var count: Int {
  5
}

Someone using a "mandatory return" rule might want the return inserted in count but not in body. There's no way we can distinguish those.

[Matejkob]

If I'm not mistaken, we cannot remove the return from do-catch, can we?

I've seen code like this in the swift-syntax repo:

func foo() -> String {
   return
     "very long string........"
}

I'm not sure if this gonna be an edge case, but I think it's worth mentioning.

[xedin]

Omitting returns could be done syntactically but injecting them requires semantic analysis because of all the features that rely on returns to be omitted.

[allevato]

Now that #596 has been merged to remove unnecessary returns, and we can't inject returns on a purely syntactic basis, I'm going to close this as there's nothing left to do.