[nolok]

Reading the list of things that worry them makes it clear that it's not so much php is breaking bc than it is wordpress lack of cleaning and linting for so long catching up to them.

I mean seriously the first thing they list as a worry is that arithmetic operators will now throw an error when one (and only one) of their operand is an array or resource (eg array + array support remains, it's really int + array or string + file_descriptor, things like that). This is literally a case that makes no sense in the code ever, not one of the "php used to do something magical for us" but "php used to keep silent about this buffonery", so if your code does that you have bigger worries ...

Almost every single one of those things are easy to fix, in that it requires mostly time not much if any redesign, and almost every single one of those things are also deprecated or on their way out since at least a decade.

[matt_kantor]

> it's really int + array or string + file_descriptor, things like that

I haven't personally used PHP in years, but was curious about this. Based on some quick/dumb experiments it appears int + array has thrown errors as far back as PHP4:

- http://sandbox.onlinephpfunctions.com/code/0b2f22ea881b36e58...

- http://sandbox.onlinephpfunctions.com/code/0e5fb752fc3ec28e8...

Is the post talking about some other scenario? Maybe the new thing is that it's now specifically a TypeError?

[hakre]

Yes, was warning / log previously, now it throws. So what was a warning and just going on is now an exception that interrupts.

[Denvercoder9]

int + array has indeed been throwing errors for a while for the basic arithmetic operations, but not for slightly more complex operations such as modulo, and there are plenty more weird combinations that used to work:

https://3v4l.org/IuoGO

[danudey]

It also sounds as though the internal type checking is going to be a large developer load as well. In PHP7, internal functions return null for type mismatches, and in PHP8, they raise a TypeError. This means going back through every case where they call an internal function and wrapping it with a try/catch for TypeError, in addition to checking for null. That sounds like a pretty significant workload change.

[Denvercoder9]

Or just make sure you pass the correct type to the functions. It's easier and probably more correct as well.

[zaarn]

If you rely on type labels on your functions and variables, you should rarely require a try/catch to handle type errors for internal functions.

[ComputerGuru]

> This is literally a case that makes no sense in the code ever,

Speaking as someone that hates PHP but still appreciates that it has its uses: You’re speaking from one perspective. There are others. That operation is perfectly valid and well-defined in Matlab where it increments all members of the matrix/vector by the scalar.

[Denvercoder9]

But PHP didn't do that, it just silently ignored the operation or returned zero. That behaviour doesn't make any sense.

[ufmace]

This is actually a perfect example of why I don't like these magical overloads for what looks like basic mathematical operations.

It's perfectly obvious to everyone what adding 2 numbers does. It works the same in basically any computer language. What happens when you add a number to an array though? There is no universal obvious rule, it depends on whatever was convenient for whoever initially wrote that overload. You just have to remember what it does in this language. Maybe it appends it to the array, maybe it does the operation on the first or last entry of the array, maybe it does it to everything in the array, or does something else entirely. Does it modify the array in place, or create another copy with the change? Woe betide anyone who forgets what it does there or gets it mixed up with another language. Better IMO to at least have functions with clear names for doing these sorts of things.

[oseityphelysiol]

Did it php use to do that? Otherwise your point is invalid.