null coalesce addition assignment operator ??+=

As mentioned earlier:
In hack (hhvm), operators like +=, *= etc do allow the left side to be
undefined.
(However, ++ and -- do not allow the left side to be undefined.)

I wonder if this is intended, or by accident.

On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker cmbecker69@gmx.de
wrote:

I propose even more such operators:
null coalesce addition assignment ??+= (for strings and numbers)
null coalesce subtraction assignment ??-=
null coalesce increment ??++
null coalesce decrement ??--
null coalesce multiplication assingment ??*=

I think this is taking it too far. If you want language like that, you
always have APL :)

Why do we discuss extensions to an operator which has still (after
nearly two years) not be implemented due to implementation
difficulties?

Am I the only one who looked at the original post and assumed he was
taking the piss?
Similar to the jokes about spaceship assignment <=>= and
equality/identicality assignment === (not to be confused with
identical non-assign, which is ===) and ====.

I can definitely say it was not a joke.
I can see myself and others use the ??+= and also ??++, and would have
used them in the past, if they had been available.
The others, I don't care as much.

For me, a good enough conclusion of this conversation would be one of:
A: Yeah seems useful, but let's wait (or work) until ??= is
implemented and released, and observe how it is being used.
B: No one will ever use it, and it would hurt the language.

Going by the example, would this operator's behaviour be a little confusing?

As I understand it the (maybe) upcoming ??= operator will assign in the
case that the lhs is not defined.
But for ??+= incrementing appears to be desired when the lhs is defined,
(with assignment to the operator related identity element in the case that
the lhs is undefined).

While the use-case seems to add value in the scenario, I think it is
possibly
inconsistent with the way ??= works?

I think it depends how you see it.

// shortcut
return $x ??= 5;
return $y ??+= 5;

// spelled out, looks inconsistent
return isset($x) ? $x : ($x = 5);
return isset($y) ? ($y += 5) : ($y = 5);

// spelled out, looks a bit more consistent (despite being broken)
return (isset($x) ? $x : ($x = 5));
return (isset($y) ? $y : ($y = 0)) += 5; // invalid code, because
ternary is not a valid lhs.

The line is invalid, but shows the mental model or the excuse that
allows us to claim this is consistent.

But yeah, I can see how someone would expect a different behavior:

return isset($x) ? $x : ($x = 5);
return isset($y) ? $y : ($y += 5);

This would not make sense or be useful because:
For $y === NULL, this would evaluate as
return $y = NULL + 5:

Still, your argument raises a valid concern that the operator might be
misunderstood.

If we get ??=, I previously thought we could use it like this, to
replicate ??+=:

return ($y ??= 0) += 5;

Unfortunately, I think we can expect that ??= won't be a valid lhs,
because neither is *= or += etc.
E.g. this is invalid:
($y *= 3) += 1;
https://3v4l.org/oKIkl

Furthermore, I think you can generalise this in user-land and end up with a
better result.

comments below.

When dealing with structured data (i.e. when you expect strings mapping to
ints in your example) you may consider writing a simple class for making
such type guarantees. Something simple like https://3v4l.org/5Sh04 would
produce the desired result, and let you obtain the result in one line at
point
of use.

Nothing ties you into using a class for the storage though, you could
simplify
even further and just create some abstract class representing an "array
toolbox"
for these kind of operations, e.g. https://3v4l.org/ZJcom
So that the array initialisation, foreach loop, and operator are replaced
with a
single line again at point of use (after defining the arraytools class
once).

If you wanted it to work more generally, you could use a reference to delay
lookup, and keep your current code structure https://3v4l.org/TJYhq

I was never a big friend of those array functions with callback
arguments, which force me to remember a signature.
I find a simple foreach() to be more readable. I think it is also faster.

So yeah, I prefer this example to the previous ones.

If you wanted it to look the part you could even sneak some unicode symbols
in to make it look like some sort of operator ;-) https://3v4l.org/MVT85

Looks interesting, but people have to type this! So, no unicode symbols.

Kind regards,
Aidan

If I were to do it in userland, it would either be

• in my own custom library or application, where it would not be used
  by others, or
• in a shared package, which other packages could add as a dependency.

I think usually people will decide against adding a dependency for a
bit of syntax sugar.
E.g. if the existing null coalesce operator was provided as a userland
solution, I don't think this package would have become popular.
Instead, code that uses such a package would become less readable, not
more readable.

I remember when I was dealing with CiviCRM, which had those "something
smart with arrays" functions.
Maybe they had the same purpose as what we discuss here, or they did
something else.
The result was: Whenever I had to look at such a call, I was confused,
and had to re-confirm what it does.
Maybe it could have gotten used to it, but I did not spend that much
time with CiviCRM.

Nowadays I prefer native features, even if they are more verbose.
They also need to be learned / gotten used to, but at least this
experience will be the same for everyone.

I also often do these kinds of array-crunching operations in throwaway
code for debugging, e.g. to build a statistic for a bunch of values.
In such cases I don't want to add a new dependency to the application.