Pitch: Multi-statement if/switch/do expressions

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.

3 Likes

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.

5 Likes