Rewrite $a ?: $b to empty($a) ? $b : $a if $a is a variable

[hikari-no-yume]

The patch for this RFC: https://wiki.php.net/rfc/isset_ternary

[smalyshev]

Isn't that a behavior change? Before, if $a didn't exist, there were notice, but after, there's no notice anymore.

[hikari-no-yume]

A behaviour change, yes, but it doesn't break backwards-compatibility. I'm writing an RFC for this as we speak, just to clarify.

[rlerdorf]

How does it not break BC? You have no idea what people might do with that notice in their custom error handlers. If you remove it, that code won't be triggered and the app will behave differently.

[hikari-no-yume]

Right, it won't break BC for most applications, but it will break things if they relied on it throwing an E_NOTICE. I'll update the RFC to note that.

[smalyshev]

OK, I didn't realize that. Within the context of RFC it makes sense. I'd support that for PHP 7.

[rlerdorf]

It seems a bit inconsistent to me that $a ? $a : $b will throw a notice and $a ?: $b won't. We would need to make that change extremely clear in the documentation highlighting the fact that ?: is now the first operator to suppress these notices and that it is now fundamentally different from its cousin, the ? expr1 : expr2 operator.

[jrbasso]

👍

[laruence]

I think even this is acceptable, it should also be done in opcache..

[hikari-no-yume]

@laruence are you saying I should rewrite the AST in opcache? Because the opcodes generated would just be cached as usual.

[laruence]

@TazeTSchnitzel I misunderstood your point as a compiler optimization.. ingore my previous comment.
I read the whole RFC .. maybe just don't trigger E_NOTICE is enough?

[hikari-no-yume]

@laruence I'd thought of just silencing errors, but I realised that causes a lot of problems. For example, it wouldn't just silence nonexistant variable/indes warnings, and I'd have to handle nested silencing (what if it calls a function)? However, implementing it as just empty($a) ? $b : $a actually works very nicely as I don't have to add any new opcodes or flags, and we already handle all those weird edge-cases.

[hikari-no-yume]

Actually, there's a second BC concern here. Because it's rewritten to empty($a) ? $b : $a it would evaluate $a twice if it's non-empty, which would cause issues if you do something which mutates state. I'm sure there's a workaround.

[smalyshev]

Well, I thought the whole point of ?: would be to use $a result immediately if it's not empty and not try to do anything else. Doing it twice definitely not a good option.

[hikari-no-yume]

@smalyshev Right, which is why I need to figure out a workaround to avoid doubly evaluating it if possible.

[laruence]

@TazeTSchnitzel hmm, in such case, I am not sure, but maybe a new syntax is more clear? PHP is a interpreting language, it's better to always make opcodes exactly reflects what the PHP codes is(at least before optimization of course)

[hikari-no-yume]

Don't worry, this is just a current problem in the patch, I'm going to figure out a way to do it that avoids double evaluation. I guess I'll have to add a new type of isset/empty operation internally.

[pk-fr]

I prefer that you implement it using isset than empty ...because the value "false" can be set and meaningfull.

the main point is to have only one access to the variable to be tested, in order to have a x2 speedup!

What about implementing a new opcode (via a new operator or a new function, whatever the syntax is) to achieve the functionnality in an "atomic" way ?

two forms of this functionality have to be considered:
$a = atomic_test_and_get($x, $condition,$value);
atomic_test_and_set($a,$condition,$value);

where $condition could be only keywords (i.e. isset , !isset, eempty, !empty, is not null, is_empty , type==double) or an expression (i.e.<=$b )

the set form would replace the $a value by the new one.

I repeat, the syntax has to be defined, but this functionnality wille be definitly needed when a real native implementation of multithreading will be implemented within php!

[staabm]

@TazeTSchnitzel will this notation also work for objects? All examples I have seen so far contained only arrays...?

[hikari-no-yume]

@staabm Yes, see the test. Though I'm now focussing on making a separate ?? operator instead.

[laruence]

Actually, I like the ?= idea....

[Majkl578]

I don't, it would be confusing for newbies, since it looks like an assignment operator (like *=).

I was thinking about:
$foo ?? exists : nope;
and shortened variant:
$foo ??: nope;