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

[Calimero]

Hello!

I suggest outright replacing Lua's existing "if statement" with an "if expression".
The expression variant would completely supersede the current statement variant, keeping exactly the same syntax.
This does not make the language bigger, but it does make it more powerful.

It would be a fully backwards-compatible change, with the value of the expression being simply ignored in existing codebases.

Details:
- Lack of an "else" branch would simply mean the value to be "nil" if no condition is true (in if or elseif branches).
- This drags along with it the idea that a block of statements evaluates to the value of its latest statement (possibly nil, if no value).


Naturally, I have read http://lua-users.org/wiki/TernaryOperator before posting this.

I am interested in knowing whether this will be implemented, or failing that, why it won't be!

[Родион Горковенко]

You probably may need to explain how it makes language "more powerful" as it seemingly duplicates existing "and / or" approach.

Proposed "if expression" may be more argued as "more readable" but it will anyway bring a number of issues - "if statement" allows multiple expressions inside (including variables definition) - how do you suggest to manage this in "if expression"?

So "it won't make language bigger" actually is a bit superficial glance.

--
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 lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/5f7ef457-8e06-e0a9-9583-144a6dbea73b%40free.fr.

[Calimero]

Hello! Here's a explicit recap of the answers to your concerns:

On 26/06/2026 09:44, Родион Горковенко wrote:
> You probably may need to explain how it makes language "more powerful" as it seemingly duplicates existing "and / or" approach.

The and/or approach has its caveats with falsy values that a proper if-then-else construct does not have.

http://lua-users.org/wiki/TernaryOperator says :
>The main caveat is that if |a| or |c| evaluates to true while |b| or |d| respectively evaluate to false, then this expression will not behave exactly like the ternary operator.

> Proposed "if expression" may be more argued as "more readable" but it will anyway bring a number of issues - "if statement" allows multiple expressions inside (including variables definition) - how do you suggest to manage this in "if expression"?

This is my suggestion to handle multiple statements:

>This drags along with it the idea that a block of statements evaluates to the value of its latest statement (possibly nil, if no value).

And to complete it, I could add that any statement that is not an expression (like a variable definition indeed) can be considered to have the value `nil`.

> So "it won't make language bigger" actually is a bit superficial glance.

What I mean by bigger is if it is one more syntactic feature.
Removing the current if statement and adding an if expression (that supersedes it perfectly) would not increase the total count of syntactic features!

This is what I meant by "not making the language bigger".

[Sewbacca]

I have seldomly the need for a true ternary operator, and almost always I can swap "a and b or c" to "not a and c or b". But it does happen that both values can be falsy in which case a true ternary operator would be useful.

I have mixed feelings about the if x then a else[if y then] b end syntax where the last value of blocks a and b are possible return values.

If Lua went down that road I would also want those semantics for the do ... end block as well, but probably not for loops and certainly not for function return values (those should be explicit).

Allthough I could be persuaded that loops are multi return blocks:

local x, y = for i = 1, 2 do
    i * i
end

local t = { for line in io.lines(".bash_history") end }

Okay maybe loops as multi return values wouldn't be that bad but I can't imagine implicit return statements for function blocks would be a good idea:

function export.login(user)
login(user, getsecret(user)) -- might leak critical information
end

~ Sewbacca

[Scott Morgan]

On 26/06/2026 14:42, 'Sewbacca' via lua-l wrote:
> If Lua went down that road I would also want those semantics for the
> do ... end block as well,

I'll +1 that. Been a few times when I've wanted to do some mildly
complex initialisation code to set a variable.

Would a do ... end block use the function stack?

Scott

[Andrey Dobrovolsky]

Greetings!

> http://lua-users.org/wiki/TernaryOperator says :
>> The main caveat is that if |a| or |c| evaluates to true while |b| or |d| respectively evaluate to false, then this expression >> will not behave exactly like the ternary operator.

In my understanding it is not a "caveat" (opinionated) but lack of parentheses.

Regards,
-- Andrew

пт, 26 черв. 2026 р. о 17:34 'Scott Morgan' via lua-l
<lu...@googlegroups.com> пише:

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/dd148aad-cd21-4207-933a-6bd0a6fddb29%40blueyonder.co.uk.

[Calimero]

Le 26/06/2026 à 17:32, Andrey Dobrovolsky a écrit :
> Greetings!
>
>> http://lua-users.org/wiki/TernaryOperator says :
>>> The main caveat is that if |a| or |c| evaluates to true while |b| or |d| respectively evaluate to false, then this expression >> will not behave exactly like the ternary operator.
> In my understanding it is not a "caveat" (opinionated) but lack of parentheses.
>
> Regards,
> -- Andrew

Well, not quite!
The caveat is still present with extra parentheses, that I can tell:

> (10 < 11) and ("yes") or ("no")
yes
> (10 < 11) and (false) or (0)
0

Can you fix the second example to return `false` as it should, by adding some parentheses? I experimented but failed.



To digress and be entirely honest, the other (and main) caveat of `condition and a or b` is that readability suffers, because objectively it is not stating its intention!
And when it's nested, I feel a bit lost: `x = a and b or c and d or e`

Cheers

[Andrey Dobrovolsky]

Hi Calimero,

Really parentheses are not enough. Dealing with variables (not some
constants) require more boilerplate:

a and b or (b and c)

-- Andrew

пт, 26 черв. 2026 р. о 18:44 'Calimero' via lua-l <lu...@googlegroups.com> пише:

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/c2d70b8b-5b43-0e2b-2130-868782ccff30%40free.fr.

[Calimero]

Le 26/06/2026 à 18:36, Andrey Dobrovolsky a écrit :
> Hi Calimero,
>
> Really parentheses are not enough. Dealing with variables (not some
> constants) require more boilerplate:
>
> a and b or (b and c)
>
> -- Andrew

Honestly I cannot comprehend the intention of that code! Is it meant to mean `if a then b else c end`?

If so, I think that this illustrates how my proposal has so much value, for its sheer clarity!
Readability matters!

Cheers

[Spar]

Funny that in LuaJIT we have the same debate with ternary operators literally right now :-)

https://github.com/LuaJIT/LuaJIT/issues/1475

--
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 lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/ab9780b9-15c7-dbf3-dd1b-727be251ad6c%40free.fr.

[Paul K]

Hi Calimero,

On Fri, Jun 26, 2026 at 8:44 AM 'Calimero' via lua-l
<lu...@googlegroups.com> wrote:
> Le 26/06/2026 à 17:32, Andrey Dobrovolsky a écrit :
> > (10 < 11) and ("yes") or ("no")
> yes
> > (10 < 11) and (false) or (0)
> 0
>
> Can you fix the second example to return `false` as it should, by adding some parentheses? I experimented but failed.

I usually just negate the condition when I run into this situation:

> not(10 < 11) and (0) or (false)
false

Paul.

[Andrey Dobrovolsky]

Hi Paul,

> I usually just negate the condition when I run into this situation:
>
> > not(10 < 11) and (0) or (false)
> false
>
> Paul.

I think the problem appears when You process variables and any of them
may be not-true. The fault mentioned by Calimero is caused by the
and-ed one.

-- Andrew

пт, 26 черв. 2026 р. о 19:50 Paul K <paulc...@gmail.com> пише:

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/CADUw5q0pqcECiUD2Y8m%2B4BV1pyrsJHZ364jzksKx-jecTU5C3Q%40mail.gmail.com.

[Calimero]

My brain hurts seeing this!
I would be fine if it were hurting because I made it work hard to produce code that is easily understandable, but this is not it.

These contorsions in fact illustrate very well why I want to keep the existing conditional syntax (except now it has a value): `if 10 < 11 then false else 0 end` is so much clearer.
I need my attention on the programming, not on the coding, and I think so do many of us!

[Andrey Dobrovolsky]

Hi Calimero,

I'm glad that You like community proposed snippets so much. I'd like
to propose a pair of even easier to understand

(select(a and 1 or 2, b, c))

({[true] = b, [false] = c})[a]

Hope You'll enjoy ))

-- Andrew

пт, 26 черв. 2026 р. о 20:16 'Calimero' via lua-l <lu...@googlegroups.com> пише:

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/0971056a-9c95-5266-dbde-3ace8b1dab86%40free.fr.

[Calimero]

Le 26/06/2026 à 20:08, Andrey Dobrovolsky a écrit :
> Hi Calimero,
>
> I'm glad that You like community proposed snippets so much. I'd like
> to propose a pair of even easier to understand
>
> (select(a and 1 or 2, b, c))
>
> ({[true] = b, [false] = c})[a]
>
> Hope You'll enjoy ))
>
> -- Andrew

I sense sarcasm, but actually there is something to say here.
In the second case, b and c would be both evaluated. And if they have effects, the effects / side effects of both b and c would happen.

This is why `if` has such a special status: it is not eager, it executes only one of the branches.

[Andrey Dobrovolsky]

> In the second case, b and c would be both evaluated. And if they have effects, the effects / side effects of both b and c would happen.

In some cases this may be not a bug but a feature, don't You think so?

Agreed, the second case is not the prefered one also because the c
variable should not be nil. Just slightly weird examples of true
ternary operators using current Lua means. Frankly speaking,
readability and understandability are subjective and may depend on
habits. Extensive usage of proposed if-expressions may appear to be
confusing for someone.

At least there are no obstacles for implementing the true ternary
conditionals just today with the current Lua.

Regards,
-- Andrew

пт, 26 черв. 2026 р. о 22:11 'Calimero' via lua-l <lu...@googlegroups.com> пише:

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/23e25cde-201b-ad0f-c741-309f19429151%40free.fr.

[Родион Горковенко]

Calimero, Hi!

Thanks for clarifications. I also have seen your discussion with Andrew about readability etc.

However I probably failed to clarify my question of internal statements and why I think your proposed change is really immense, not a syntactic sugar.

Your suggested feature allows us to create new variables inside the expression, i.e. expression will affect outer scope.

a = if x > 1 then b = 13 end

Unless I had forgotten something or we use dirty tricks on globals table , expressions are restricted from such behavior.

So you actually propose to create completely new semantics of expression/statements (or something in-between).

This is significant change from the viewpoint both of the source code and of the language paradigm. Do we really need this?

Perhaps we may want something different for ternary operator?

What you propose, blocks with value calculated by the last statement, surely exists in other languages but I think generally with languages which use isolated scope for blocks.

sincerely yours,

Rodion

--
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 lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/6347a9ea-2bf8-7fdb-c59a-8d4d93ead14a%40free.fr.

[Luther Thompson]

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

[Calimero]

Le 27/06/2026 à 08:15, Родион Горковенко a écrit :
> Calimero, Hi!
>
> Thanks for clarifications. I also have seen your discussion with Andrew about readability etc.
>
> However I probably failed to clarify my question of internal statements and why I think your proposed change is really immense, not a syntactic sugar.
>
> Your suggested feature allows us to create new variables inside the expression, i.e. expression will affect outer scope.
>
> a = if x > 1 then b = 13 end
>
> Unless I had forgotten something or we use dirty tricks on globals table , expressions are restricted from such behavior.
>
> So you actually propose to create completely new semantics of expression/statements (or something in-between).
>
> This is significant change from the viewpoint both of the source code and of the language paradigm. Do we really need this?
>
> Perhaps we may want something different for ternary operator?
>
> What you propose, blocks with value calculated by the last statement, surely exists in other languages but I think generally with languages which use isolated scope for blocks.
>
> sincerely yours,
> Rodion

Ooh, interesting remark, that!
I suddenly thought I hadn't understood the language well enough, so I investigated this.

A relevant remark is that a local variable declared in a loop, *as well as in an if statement*, does not exist any more outside of that loop or if statement.


For the sake of assurance, I ran this:

for i = 1,3 do local a = "a local variable leaked out of a loop" end
print(a)

if true then local b="a local variable leaked out of an if statement" end
print(b)

function f1() local c="a local variable leaked out of a routine" end
_ = f1()
print(c)

for i = 1,3 do d = "a global variable leaked out of a loop" end
print(d)

if true then e="a local variable leaked out of an if statement" end
print(e)

function f2() f="a global variable leaked out of a routine" end
_ = f2()
print(f)

Of course globals "leak" everywhere all the time.

The above code makes the point that it's entirely possible to be calling a routine in an expression and define a global there too.


I conclude that while your remark was very relevant, in the end it entails no concerns, as it is possible to keep the behaviour of the if statement when turning it into an if expression.
Indeed, the current if statement erases locals declared in one of its branches!

This makes sense, because having variables that could be declared or not depending on the branch taken would cause headaches. My thanks to the designers of Lua for this.


Thanks again for your remark, this was worth double-checking. All good, apparently. In my eyes this consolidates that my suggestion has good compatibility with Lua as it exists today.

Cheers!

[Calimero]

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!

[Andrey Dobrovolsky]

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 <lu...@googlegroups.com> пише:

> --
> 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 lua-l+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/lua-l/461e2afa-85fc-5d9f-5e94-ac5eefc4959e%40free.fr.

[Calimero]

Le 27/06/2026 à 16:36, Andrey Dobrovolsky a écrit :
> Btw Pluto already has both ternary operator and if-expressions,
> https://pluto-lang.org/docs/New%20Features/Ternary%20Expressions
>
> -- Andrew

That's great! Apparently the idea I'm pushing is not new at all.
All the better!


On a tangent:
Speaking of having more syntax for no particular reason (a ternary conditional operator for example), I think John Backus in his Turing Award paper put it better than I ever could:

>Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak. They're primitive, word-at-a-time style of programming, inherited from their ancestor, the Von Neumann computer.

He was advocating for more attention to "whole images", meaning referentially transparent expressions that assemble to a value.

[Federico Ferri]

The use of x and y or z is good only for selected trivial cases.

However nothing prevents you to write a more robust helper:

function _if(cond, _then, _else)
    if cond then return _then else return _else end
end

print(_if(10 < 11, 'yes', 'no')) -- yes
print(_if(10 < 11, false, 0)) -- false

And you can add as much syntactic sugar as your use-case needs:

function _if(cond, value)
    return setmetatable({
        _ = {{{cond, value}}, nil},
        _elseif = function(self, cond, value) table.insert(self._[1], {cond, value}) return self end,
        _else = function(self, value) self._[2] = value return self end,
    }, {
        __call = function(self)
            for _, entry in ipairs(self._[1]) do
                local cond, value = table.unpack(entry)
                if cond then return value end
            end
            return self._[2]
        end,
    })
end

print(_if(10 < 11, 'yes'):_elseif(true, 'no'):_else(8)()) -- yes
print(_if(10 > 11, 'yes'):_elseif(true, false):_else(8)()) -- false
print(_if(10 > 11, 'yes'):_elseif(false, 'no'):_else(8)()) -- 8

But, to be honest, I'd like Lua to provide a mechanism to allow me write *better* syntax sugar which would allow me to solve 100 different problems, rather than just one solution to one problem (the ternary operator) which is a nice to have, but it may or may not fit the minimalistic design of Lua.

--
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 lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/5f7ef457-8e06-e0a9-9583-144a6dbea73b%40free.fr.

[Francisco Olarte]

On Fri, 26 Jun 2026 at 20:08, Andrey Dobrovolsky
<andrey.dobro...@gmail.com> wrote:
> I'm glad that You like community proposed snippets so much. I'd like
> to propose a pair of even easier to understand

> ({[true] = b, [false] = c})[a]

({[true] = b, [false] = c})[not not a] -- Or just one not and
invert indexes.

Francisco Olarte.

[Calimero]

Le 27/06/2026 à 17:37, Federico Ferri a écrit :
> The use of x and y or z is good only for selected trivial cases.
> However nothing prevents you to write a more robust helper:
>
> function _if(cond, _then, _else)
>     if cond then return _then else return _else end
> end
>
> print(_if(10 < 11, 'yes', 'no')) -- yes
> print(_if(10 < 11, false, 0)) -- false

The problem is that this eagerly evaluates boh the _then and the _else.

It costs performance, but more importantly if there are effects, the effects of both branches are executed.

> But, to be honest, I'd like Lua to provide a mechanism to allow me write *better* syntax sugar which would allow me to solve 100 different problems, rather than just one solution to one problem (the ternary operator) which is a nice to have, but it may or may not fit the minimalistic design of Lua.

The conditional is a very fundamental notion in programming, and there is a fundamental flaw in not having an expression conditional.
I'm trying to deal with this.

I do think that it will solve more many problems to have a clean conditional expression.

So… you basically want to allow programs to introduce new syntax? Wouldn't something like user-defined mixfix operators be the minimum necessary to achieve this satisfactorily?

[Francisco Olarte]

On Sat, 27 Jun 2026 at 08:16, Родион Горковенко <rodio...@gmail.com> wrote:
...

> However I probably failed to clarify my question of internal statements and why I think your proposed change is really immense, not a syntactic sugar.
> Your suggested feature allows us to create new variables inside the expression, i.e. expression will affect outer scope.
> a = if x > 1 then b = 13 end
> Unless I had forgotten something or we use dirty tricks on globals table , expressions are restricted from such behavior.

The original extension was not specified nearly enough for me, and
further clarificacions were not of much help, as they began to mix
if-expressions with "(nearly) every statement is an expression", what
allows C to do a=b=1.

If you tackle it by parts, the if-expression, lets call it IF for now
to avoid collisions in the parser, is not much than adding "| IFexp"
to the or chain in exp and defining "IFexp ::= IF exp THEN exp {
ELSEIF exp THEN exp } [ ELSE exp ] end" in "The complete syntax of
lua".

In this case, as with the classic and-or, assignments will be illegal,
as they now are inside exps ( anyway, if yu were caring about the
globals table, they are already possible, "a=(x>1) and
rawset(_ENV,"b",13)", and cookedset is a one liner if you like to play
with metatables in globals.

OTOH making assignments an expression opens a real can of worms. This
would seem to need a deep change.

I like my ternaries, and would love to have them in Lua. As I would
love to have lot of other operators, like op-assign of every variety,
which I think would improve readabilty in some of the most unreadable
places of my code, as well as null coalescing or those fancy elvis
operators, but I fear powers that be want to keep Lua simple.

Francisco Olarte.

[Francisco Olarte]

On Sat, 27 Jun 2026 at 18:56, 'Calimero' via lua-l
<lu...@googlegroups.com> wrote:
> The conditional is a very fundamental notion in programming, and there is a fundamental flaw in not having an expression conditional.
> I'm trying to deal with this.

The conditional is fundamental, the ternary ( or the funky IF
expression I drafted previously ) is not. After all we put some men on
the moon more than fifty years ago without ternaries ( take "we" as
"the humanity", assume no foul play in the banner photos ). And lot of
languages do not have them.

If-expression is nice, but I would put it after op-assign in priority,
and maybe after elvis. But before postincrement, if I ever did that
one, and anyway to bne useful that need to redefine what a expression
is first.

( And I would vote against a pythonesque x if cond else y )

Francisco Olarte.

[Lan Krownet]

Operator assignment is not necessarily the only way to do it, because the issue assignment operators are trying to solve is not having to retype a really long variable, well, you could have a single unary prefix operator with a number that basically takes the variable being assigned in the expression and pastes it into the code like

areallylongvariable = $0+1

turns into

areallylongvariable = areallylongvariable+1

or it could point to any section, which is nice when you just want to swap some variables

var1, var2 = $2, $1 -- variables are swapped

But anyway.

--
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 lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/CA%2BbJJbw7igVMU6ziHXcWoC5CJTXqpTCQPy-go0dauhgEqo1VAw%40mail.gmail.com.

[Francisco Olarte]

On Sat, 27 Jun 2026 at 19:29, Lan Krownet <khw...@gmail.com> wrote:
>
> Operator assignment is not necessarily the only way to do it, because the issue assignment operators are trying to solve is not having to retype a really long variable, well, you could have a single unary prefix operator with a number that basically takes the variable being assigned in the expression and pastes it into the code like

IMO the retyping is not the problem.

> areallylongvariable = $0+1
> turns into
> areallylongvariable = areallylongvariable+1

This is some kind of preprocessor trick. Useful, but there are things like:
f(a).x.g(b)[h(d+e)]*=2 where, due to potential side effects, you can
not use it. And even without them you will hit a runtime penalty. I
mean, in lua you cannot substitute a.b.c.d=a.b.c.d+1 with do local x =
a.b.c x.d=x.d+1 end. So that rules out the preprocessor tricks and
either imposes a runtime penalty or forces you to exactly define the
semantics. In fact I fear this need is one of the arguments for not
having op-assign. In C, where you have addresses, it is easier as you
can define x+=1 as y=&x; *y=*y+1. But in lua = is a complex beast.

Besides, coming from old assemblers, and C/C++/perl, I've found a+=7
is a more fundamental op than a=a+7, I'm used to do think on it as
"add a,1" and "add_and_store a,b,1". In fact when you overload
operators in C++ you normally do it that way.

> or it could point to any section, which is nice when you just want to swap some variables
> var1, var2 = $2, $1 -- variables are swapped

Once you "preprocess" you can also macro that, that is why I like
having preprocessors. You do not use much but when you have half a
page of swaps they are nice and let you give names to things without
cost. But I'm disegressing, so lets sign out.

Francisco Olarte.

[Sewbacca]

I think I would quite enjoy += etc. if we get matching metamethods. So eventhandler += function() end could be a thing.

I am not quite sure though if there would be potential costs (implementation, parsing or language semantic wise) that would make this a bad decision.

[Calimero]

Le 27/06/2026 à 19:02, Francisco Olarte a écrit :
> The original extension was not specified nearly enough for me, and
> further clarificacions were not of much help, as they began to mix
> if-expressions with "(nearly) every statement is an expression", what
> allows C to do a=b=1.

Ouch no, I do not want "every statement is an expression". Statements should remain satements.

Thankfully, allowing *expressions* to qualify as statements doesn't allow something like a=b=1!

I think there is no need to say that statements must be expressions to achieve valued code blocks (and the if expression I propose as a drop-in replacement for the if statement).

The fact that a code block ending in a statement gives `nil` when we try to derive a value from it does not change this.
Statements still cannot be used as parts of an expression with just this.

Le 27/06/2026 à 19:11, Francisco Olarte a écrit :
> On Sat, 27 Jun 2026 at 18:56, 'Calimero' via lua-l
> <lu...@googlegroups.com> wrote:
>> The conditional is a very fundamental notion in programming, and there is a fundamental flaw in not having an expression conditional.
>> I'm trying to deal with this.
> The conditional is fundamental, the ternary ( or the funky IF
> expression I drafted previously ) is not.

No, the conditional expression is just as fundamental as the conditional statement.
They are even two instances of the same idea, which is why I suggest to make them the same entity.

Could you argue otherwise? (not involving personal preference for imperative code)

> After all we put some men on
> the moon more than fifty years ago without ternaries ( take "we" as
> "the humanity", assume no foul play in the banner photos ). And lot of
> languages do not have them.
>
> If-expression is nice, but I would put it after op-assign in priority,
> and maybe after elvis. But before postincrement, if I ever did that
> one, and anyway to bne useful that need to redefine what a expression
> is first.

Well, we can all have a personal preference when it comes to priorities. (actually, as it concerns lua, I don't!)
Our personal preferences will just decide where we will each contribute our respective effort.

As long as the various ideas being worked on are compatible with one another, this is totally fine!

There are no interactions to discuss between op-assign and if-expression topics, I think?
As far as conditionals are concerned, op-assign is an instruction like any other, and as far as op-assign is concerned, if-expressions are an expression like any other.
If they are indeed unrelated, then there is surely no reason to discuss these unrelated features in this thread.

And in any case, on my end I have no intention to make any claims on what should be a priority in the development of lua.

> ( And I would vote against a pythonesque x if cond else y )

You didn't say your reasons, that would be interesting to know.

It just so happens that I agree with your opinion, and I can give my reason for that:
Lua already has a perfectly good conditional syntax, why should we need to invent another? Keep it simple!

[Francisco Olarte]

On Sun, 28 Jun 2026 at 15:07, 'Calimero' via lua-l
<lu...@googlegroups.com> wrote:
>
Le 27/06/2026 à 19:02, Francisco Olarte a écrit :
> > The original extension was not specified nearly enough for me, and
> > further clarificacions were not of much help, as they began to mix
> > if-expressions with "(nearly) every statement is an expression", what
> > allows C to do a=b=1.
>
> Ouch no, I do not want "every statement is an expression". Statements should remain satements.
> Thankfully, allowing *expressions* to qualify as statements doesn't allow something like a=b=1!

Why thankfully? It is an useful idiom, used not in every page but a
lot on languages that allow it.

> I think there is no need to say that statements must be expressions to achieve valued code blocks (and the if expression I propose as a drop-in replacement for the if statement).

mmmm, not, but you will probably need part of it. Unless you define a
valued code block as something like DO-stat*-exp-END.

> The fact that a code block ending in a statement gives `nil` when we try to derive a value from it does not change this.

Well, you can do it that way. Is just a little bit more complex.

> Statements still cannot be used as parts of an expression with just this.

Well, then your proposal is even more difficult to understand to me.
I'lkl just wait till this wraps aup a bit and rered it them.

> >> The conditional is a very fundamental notion in programming, and there is a fundamental flaw in not having an expression conditional.
> >> I'm trying to deal with this.
> > The conditional is fundamental, the ternary ( or the funky IF
> > expression I drafted previously ) is not.
> No, the conditional expression is just as fundamental as the conditional statement.

You are missquoting me. I did not say "The conditional statement" is
fundamental. Anyone can see why I avoided it ( hint - we are talking
notion in programming, not lua programming there ).

> They are even two instances of the same idea, which is why I suggest to make them the same entity.

Here you are getting where I was, cond. stat. and cond. exp. are forms
of "The Conditional". What I was stating is you can have a language
with any form of "the conditional".

> Could you argue otherwise? (not involving personal preference for imperative code)

Itry to never argue after a missquote until I manage to be able to
understand its reason.
...

> There are no interactions to discuss between op-assign and if-expression topics, I think?

I fear a proper op-assign, in lua, will interfere with nearly
everything. Should I try to modify lua ( under my present constraints
I will probably not do it as the PUC development model makes it
difficult and I would not want to risk a fork ) I will probably start
with ternaries ( or if expression if you like ) as I feel they should
be reasonably easy to do. I wrote a proposal using IF IIRC some
messages above, this would deal with ternary-equivalent. But your
proposal, allowing arbitrary statements, is much more ambitious and
will need to redefine things, probably define something like a
block-expression, and once you go in there I probably would prefer to
just drop lua and use another language.

> As far as conditionals are concerned, op-assign is an instruction like any other, and as far as op-assign is concerned, if-expressions are an expression like any other.

See, this talking of "instruction" and "expression" intermixed is what
makes reasoning on your proposal hard.

> If they are indeed unrelated, then there is surely no reason to discuss these unrelated features in this thread.
>
> And in any case, on my end I have no intention to make any claims on what should be a priority in the development of lua.
>
> > ( And I would vote against a pythonesque x if cond else y )
> You didn't say your reasons, that would be interesting to know.

Sexy reasons :->... No, I just dislike how it reads. But it has the
real advantage of MANDATING if and else, i.e., ternary.

> It just so happens that I agree with your opinion, and I can give my reason for that:
> Lua already has a perfectly good conditional syntax, why should we need to invent another? Keep it simple!

Lua has a perfectly good conditional statement syntax. It has no
conditional expresion. If you do it in my simplified like IF cond THEN
then-exp ELSE else-exp END ( I would start with mandatory ELSE, think
on optional one later, as the value has three perfectly legal default
else ( nil, false and whatever cond returns, which makes it equal to
'cond AND then-exp ). You could probably fix it. If you want to allow
multi-line ifs wyou have to defie the syntax ( remember in lua an
expresion is not an statement, so you can not reuse the "block"
syntax, you would have to make something like "{stat} exp", then
decide on the nil default if youlike it. Simple ternary is easy,
adding elseif also easy ( but nor that easy as I forgot the danglinl
else problem in a previous mail ).

You could try to do a minimal augmentation to "the complete syntax of
lua" to present the alternatives, this would let people, me the first,
see a bit clearer.

ta-ta.

Francisco Olarte.