Re: Replacing the "if" statement with an "if" expression which supersedes it

Btw Pluto already has both ternary operator and if-expressions,
https://pluto-lang.org/docs/New%20Features/Ternary%20Expressions

-- Andrew

сб, 27 черв. 2026 р. о 17:03 'Calimero' via lua-l <[email protected]> пише:
>
> Le 27/06/2026 à 15:12, Luther Thompson a écrit :
> > I should point out that Lua does not allow an expression to be a statement (unless it's a function call), so letting the last statement of a block be the value of that block would be a major change in the grammar.
> >
> > Also, while I'd love to see a true ternary operator in Lua, it is fundamentally different from an if-else statement, and I don't think they should be unified. A ternary operator is a single expression resolving to a single value. An if-else can contain multiple statements, which makes side-effects more likely to happen.
> >
> > Luther
>
>
> Hello!
>
> That is a good point.
> Precisely due to the strange exception that routine ("function") calls are both expressions and statements, I had not noticed that and was assuming that expressions worked as statements, reinforced in that misunderstanding by the REPL's behaviour!
>
> Do you think this (yes, profound) change of accepting expressions as statements would be a bad one?
> If so, I would agree with that, but then I would immediately draw the logical consequences and want to fix that strange exception you noted, about the callable entities declared with the keyword `function`, whose calls can be valid statements despite being (also?) expressions.
>
> Maybe Lua needs to acquire a `proc` or `procedure` keyword that declares works as a statement, and to make calls to `function`s invalid as statements.
> Functions would only be allowed to contain an expression — no statements.
> ...but *that* would be a backwards-incompatible, breaking change. And probably regarded as a very bad move.
>
> # (abandoning this line of thought and returning to my initial proposal's consequences) #
>
> At least, accepting expressions as statements would restore consistency in a backwards-compatible way.
> Warning when a non-nil value was ignored could also make a lot of sense.
> Thinking about backwards compatibility, this would cause new warnings in programs that called "functions" that return a value without using it. This would probably be a good thing, too: I can imagine this leading to welcome bug fixes.
>
> Currently, it is indeed a syntax error as you pointed out, which is different in nature.
> But I think the language would be cleaner, more regular, if it systematically accepted expressions that evaluate to nil as statements.
>
> Cheers!
>
>
> --
> You received this message because you are subscribed to the Google Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion visit https://groups.google.com/d/msgid/lua-l/461e2afa-85fc-5d9f-5e94-ac5eefc4959e%40free.fr.

-- 
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/CAN5FJ7eMmKYBLyC1VC%2BbUzBV%3DCzW1W8LgWbxjyGAaZpjUqt1jg%40mail.gmail.com.