SE-0380: `if` and `switch` expressions

[hamishknight]

@Douglas_Gregor

The discussion here seems to be leaning toward allowing a return inside an if or switch expression, e.g.,

let value = if array.isEmpty { 0 } else { return 3 }

@Paul_Cantrell notes that peer languages allow this, but I think they all got it wrong. As @ktoso notes that this is considered an anti-pattern in Scala, and I think it's worse for Swift. Right now, the only way for control flow to exit out of an expression is via a thrown error, and we consider that to be so important that we require any throwing expression to be marked with try to indicate to readers that this control flow out of the expression can happen. Similar reasoning follows for suspension points with await. Having an expression that has control flow out of itself would undermine this long-held philosophy in Swift.

To clarify, as currently proposed, if/switch expressions do not have to be marked with try or await if the branches may throw or suspend, as those actions will be explicitly called out within the branches themselves with try/throw/await. For example, you can write:

func foo() throws -> Int {
  let x = if .random() {
    throw SomeError()
  } else {
    5
  }
  return x
}

and:

func foo() throws -> Int {
  let x = if .random() {
    try someThrowingFunction()
  } else {
    5
  }
  return x
}

without writing try if.

I thought this was mentioned in the proposal, but it seems like it isn't. It did however come up in the pitch thread.

If we were to enforce try if/await if, then I agree it might make sense to ban return, as there's no equivalent keyword to mark the expression. However I'm not convinced that we should enforce try if/await if, as IMO it would be unnecessary noise, especially for the cases currently being proposed (bindings, implicit returns, etc.). As such, banning return while allowing throw and try would seem odd to me, as they are all able to exit the function, and are just as explicit as each other.

@Douglas_Gregor

It's also very easy to make a mistake with this feature; a stray return (say, due to refactoring) would exit the function rather than produce the intended value

I mean, this is true of any refactoring where you're taking code that was previously in a closure and bringing it into a parent function, I'm not convinced it's sufficient grounds to outright ban return in if/switch expressions.

That being said, I'm not against banning return for now and re-examining it when we consider allowing if/switch expressions in arbitrary positions (where IMO return may be more contentious).