Discussion: making continue and break into an expression

Hello internals,

Now that throwing is an expression, it allows for some very concise
programming. What are your thoughts on making a break/continue into an
expression as well?

Instead of:

while(true) {
...
if(is_null($arr['var'])) continue;
if($something) continue; else break;
...
}

You could write

while(true) {
...
$arr['var'] ?? continue;
$something ? continue : break;
...
}

Robert Landers
Software Engineer
Utrecht NL

--

To unsubscribe, visit: https://www.php.net/unsub.php

Me personally would love to see return receive such treatment too!

(for a SerenityOS-like pattern of returning ”ErrorOr”-like objects)

P.S. sorry for a simple ”me too” reply

Hi Robert

On Thu, Jan 25, 2024 at 10:16 AM Robert Landers
landers.robert@gmail.com wrote:

Now that throwing is an expression, it allows for some very concise
programming. What are your thoughts on making a break/continue into an
expression as well?

Instead of:

while(true) {
...
if(is_null($arr['var'])) continue;
if($something) continue; else break;
...
}

You could write

while(true) {
...
$arr['var'] ?? continue;
$something ? continue : break;
...
}

This leads to very similar issues as break/continue inside blocks. See:
https://wiki.php.net/rfc/match_blocks#technical_implications_of_control_statements

I'll try to explain.

The VM works with temporary variables. For the expression foo() +
bar() two temporary variables for the result of foo() and bar() will
be created, which are then used for the + operation. Normally, + will
consume both operands, i.e. use and then free them. However, with
break/continue etc. being expressions, it would become possible to
skip over the consuming instructions.

do {
    echo foo() + break;
} while (true);
echo 'Done';

Pseudo opcodes:

0000 V1 = CALL foo
0001 JMP 0005
0002 V2 = ADD V1 false ; false is here represents a bottom value

that will never actually be used
0003 ECHO V2
0004 JMP 0000
0005 ECHO 'Done'

Since JMP will skip over the ADD instruction, V1 remains unused. A
similar problem already exists for break/continue in foreach itself.

foreach ($foos as $foo) {
   foreach ($bars as $bar) {
       break 2;
   }
}

foreach holds a copy of $bars (in case it gets modified) that normally
gets cleaned up when the loop ends. With break over multiple
loop-boundaries, we can completely skip over this freeing mechanism.
PHP solves this by inserting an explicit FE_FREE instruction before
the break 2, which itself is essentially just a JMP to the end of the
outer loop.

Hopefully it's now more evident why this is a problem:

while (true) {
   foo() && break;
}

foo() returns a value that would normally be consumed by the &&
operation. However, with break, we may skip over the && operation
entirely. As such, the break itself becomes responsible for freeing
these values. This requires significant changes in the compiler to
track variables that are currently "live" (i.e. haven't been consumed
yet), and emitting FREE opcodes for them as needed. I've implemented
this for match blocks here:

https://github.com/php/php-src/compare/master...iluuu1994:php-src:match-blocks-var-tracking

However, note that due to complexity, I've decided to disallow using
break/continue and the likes in such contexts to avoid this issue
completely, which isn't possible for what you are suggesting.

There's another related issue.

foo(bar(), break);

Function calls in PHP consist of multiple instructions, namely an
INIT_CALL, 0-n SEND and a DO_CALL opcode. INIT_CALL creates a stack
frame, SEND pushes arguments onto the stack frame, and DO_CALL starts
the execution of the function and frees both arguments and stack frame
when the function ends. If prior to a SEND opcode we break, we skip
over the DO_CALL, so the stack frame needs to be freed manually.

The patch linked above solves this by inserting CLEAN_UNFINISHED_CALLS
opcodes that do as the name suggests. This mechanism is already used
for exceptions. This should work for you, but was insufficient for
match blocks, for reasons I won't get into here.

All this to say: Don't expect the implementation here to be trivial.

Regards,
Ilija