Allow a reordered version of the ternary conditional operation

[awardell]

Presently, a ternary operation takes the form:

output= option_a if some_condition else option_b

This is serviceable and mirrors Python's implementation, but has two issues of readability. First, it is not immediately apparent upon glancing at the line that we are entering a ternary statement. If one were skimming over a large file, they might think this were a simple assignment rather than a branching assignment with a test.

Second, it is visually ambiguous as to the order in which the interpreter will evaluate each part of the statement, and whether or not a part of the statement will be evaluated or will be short-circuited. If option_a were a method option_a(), and some_condition is false, then will option_a() ever be evaluated? The answer is no; it will be short circuited, but that is not obvious from looking at the line.

Some discussion on this matter was had on this thread years ago: godotengine/godot#1961

I propose an alternative ordering to the ternary operation:

output = if some_condition then option_a else option_b

Upon seeing this code, it is much more immediately obvious what the line does and how it behaves. The short-circuiting behavior seems obvious because it follows the convention of a typical if/else statement. I don't believe the "then" keyword exists in godot presently, so this would require its introduction, but I think it would be worth it. Alternatively, a colon could be used in place of "then", but then it wouldn't be as pretty, would it?

If more of this discussion has already been had elsewhere, please point me to it, but I couldn't find anything. And please correct me if I am making any incorrect statements here. Thank you!

[Calinou]

I don't believe the "then" keyword exists in godot presently, so this would require its introduction, but I think it would be worth it. Alternatively, a colon could be used in place of "then", but then it wouldn't be as pretty, would it?

I would prefer making if and match usable as expressions that return a value (like in Rust), which entails using : instead of a then keyword.

However, this is a large change that will likely break existing syntax. I'm not even sure if it can be done without introducing ambiguities in the parser.

[awardell]

I like the idea. Are you saying this proposal would cause those issues, or just that your suggestion would?

[Calinou]

Are you saying this proposal would cause those issues, or just that your suggestion would?

My suggestion would potentially cause those issues, not yours. Yours is easier to implement, but having then in a language with Python-like syntax feels weird to me. then is usually reserved for languages with keyword-based syntax such as Ruby, Lua and shell script.