Comment by drunken_thor
7 hours ago
I think that allowing an if statement to return a value to deal with the ternary introduces a now concept to Lua and that is that the value on the final line of a block is a return value much like Ruby. This changes the logic of the entire language more than adding a ternary. I do prefer the if statement as it allows so much more emergent behaviour, but it does have more implications to consider.
I suppose, though I feel what most people in this thread are thinking of is updating the existing if statement to also work as an expression, which does have plenty of implications (not that I think they would be bad, just more of a change to the language than the feature designers were going for) including final returns. The example I took from Luau still keeps the if statement and the if-then-else expression as separate constructs. One problem is that the statement and expression versions look very similar despite having different semantics (expression version must only contain expressions in its branches, must have an `else` case, does not have `end`).
Of course there are differences between LuaJIT and Luau that I think influence their decisions on possible ternary expression features:
- Luau users are disproportionately beginners to programming that I believe would find the if-then-else expression syntax easier to learn; LuaJIT developers have a larger user base of professional devs wanting to make their code faster, and they will probably be more familiar with the `x ? y : z` style since it's used in plenty of other languages.
- Luau is a lot faster moving in its development than LuaJIT in terms of language features, the Luau team just wanted to move people to ternaries from `x and y or z` because it's easier to optimise in a normal interpreter; LuaJIT, with their JIT, I assume would be able to more easily implement optimisations for constructs like `x and y or z` despite its slight semantic differences (my assumption on why the change is being considered now rather than earlier).