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?
Hi!
I had similar idea to make break, continue and return be expressions instead of statements to simplify almost the same cases as Robert described above.
On Sun, Feb 2, 2025 at 2:36 PM Dmitry Derepko <xepozzd@gmail.com> wrote:
I had similar idea to make `break`, `continue` and `return` be expressions instead of statements to simplify almost the same cases as Robert described above.
Thinking about Ilija memory leaking case:
new Foo + return 1
I think we may have a workaround here, by allowing all of these constructions only available at some specific points:
- <point> as the statement now
- $cond ? <point> : <point>;
- match ($v) { … => <point> }
So it will deny such cases:
- operand OPERATOR <point> (1 + return; $cond && break; etc)
It may prevent memory leaking problems. Isn’t it?
Note that technical discussions don't need to happen on the internals
mailing list. It has a lot of recipients and they are usually not
interesting to the majority of people. GH is a better place for that.
This alone will not be sufficient, because the ?: and match
expressions themselves may be nested in other expressions that create
temporary variables. E.g. new Foo + ($cond ? $x : break) will create
the same issue. Restricting control flow statements fully to a
combination of these expressions would work, however is also less
useful and thus less persuasive. In my experience, incomprehensible
limitations are generally not well received by 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?
Hi!
I had similar idea to make break, continue and return be expressions instead of statements to simplify almost the same cases as Robert described above.
I’ll start a new discussion when it will be ready for it.
Best regards,
Dmitrii Derepko.
@xepozz
Oh, this was a fun one!
I ended up rewriting the AST during compilation (pass 2) to return/break on the next statement instead of in the current statement. That let me get around the issue but I guessed nobody would like it and it probably wouldn’t pass on technical reasons.
In other words, yes it was an expression on the grammar level, but it was compiled as a statement.
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?
Hi!
I had similar idea to make break, continue and return be expressions instead of statements to simplify almost the same cases as Robert described above.
I’ll start a new discussion when it will be ready for it.
Best regards,
Dmitrii Derepko.
@xepozz
Oh, this was a fun one!
I ended up rewriting the AST during compilation (pass 2) to return/break on the next statement instead of in the current statement. That let me get around the issue but I guessed nobody would like it and it probably wouldn’t pass on technical reasons.
In other words, yes it was an expression on the grammar level, but it was compiled as a statement.
— Rob
Hello again,
I just finished reviewing the diff and didn’t notice any tests that show what the value of things actually become. In my diff, I did something like this:
$this->x = return $y; // $this->x === $y
Which is basically shorthand for:
$this->x = $y;
return $y;
An empty return, break, or continue (well, only one of these has a value) contains the value NULL:
$this->x = break; // $this->x === null
Shorthand for:
$thix->x = null;
break;
I’m trying to figure out which branch this was on … but it was likely on my old computer since I originally sent it the email from my gmail address.