Pitch: Multi-statement if/switch/do expressions

[jeremyabannister (Jeremy Bannister)]

@xwu

It is completely out of the question for a programming language to deliberately choose to design a feature in such a way that someone typing x: 1000 lines up or moving some code into a loop can completely change the meaning of a statement such that instead of an expression being evaluated to a value it turns into a control flow statement that breaks out of an outer loop.

Is this not solvable by producing an error if there is an ambiguity? Adding x: would cause the break x to produce an error because of the new ambiguity with the value named x. I like some of the upsides of using break that @Val describes, and I’m also dubious of how it reads to use “break” in a situation where the meaning is akin to “return”. But the argument you provided (that it produces unacceptable unpredictability when modifying code) didn’t make sense to me (yet), given the option of diagnosing ambiguity with an error.

[xwu (Xiaodi Wu)]

@jeremyabannister

But the argument you provided (that it produces unacceptable unpredictability when modifying code) didn’t make sense to me (yet), given the option of diagnosing ambiguity with an error.

That would make existing valid code an error anywhere a label has the same spelling as any identifier in scope at that point in the code by putting them in the same namespace. You could try to limit the error to only contexts inside an if/switch/do expression, but then the diagnostic would have the same action-at-a-distance problems. And regardless, a reader would not actually be able to know what sort of control flow statement break foo is without context.

This is basically like wondering whether we could “solve” a design where if, guard, switch, and do are all spelled if—not sure why this is being entertained 450 replies into a thread about making the language more joyful to write.

[Jeehut (Cihat Gündüz)]

If I understand this pitch correctly, it would allow me avoid writing this code:

let data: Data
let response: URLResponse
do {
   (data, response) = try await URLSession.shared.data(for: request)
} catch {
   throw RequestError.failedToLoadData(error)
}

And instead I could write this much more readable and convenient code:

let (data, response) = do {
   try await URLSession.shared.data(for: request)
} catch {
   throw RequestError.failedToLoadData(error)
}

Do I understand that right?

For this aspect alone, I'm supporting this pitch. I'm not so sure about the introduction of a then keyword though, I don't find it very intuitive on first read of the proposal. The aspect I'm most interested in is the allowance of do-expressions. It might be added in a much narrower proposal. I pitched another change here to solve the same problem:

[Pitch] Introducing do-let-catch for Cleaner Error Handling

I recently encountered a scenario where I found the existing syntax in Swift unnecessarily complex and less readable: let data: Data let response: URLResponse do { (data, response) = try await URLSession.shared.data(for: request) } catch { throw RequestError.failedToLoadData(error) } I believe it would be far more readable and concise if we could write it this way: do let (data, response) = try await URLSession.shared.data(for: request) catch { throw RequestError.failedToLoadData(err…