On Mon, 28 Feb 2022 at 22:11, Christian Schneider <cschn...@cschneid.com> wrote:
> Am 28.02.2022 um 22:05 schrieb Christoph M. Becker <cmbecke...@gmx.de>: > > The BC break doesn't appear to be that serious after all. > > I'm not sure I get your point here: If you provide a user-land > implementation of the previous behavior under a different name then the BC > break cannot be serious? > > - Chris > Yeah, I'm not sure what the point is either... sorry, I thought the suggestion was a joke, and replied off-list as such, but creating replacement userland functions for all of these functions, and to update all code to use those functions... maybe I'm missing something. And because I'm back to tired pissed-off sarcasm masking depression (why bother spending days on a solution that works for everyone when we can make a hostile/elitist environment/language)... maybe we could simply suggest that everyone affected by this should use strval() for everything? Admittedly the following only does 1 parameter, with a single variable, but at least this is one way to dismiss/ignore the problem: sed -i -E 's/(htmlspecialchars)\((\$[a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*)\)/\1(strval(\2))/i' index.php As to voting at: https://quiz.craigfrancis.co.uk/ So far it's 10 votes to continue supporting null coercing for those not using `strict_types=1` (as PHP always has always done with internal functions, and non-strict comparison operators)... 10 votes to ignore the problem and make a hard backwards compatibility break for PHP 9.0... and 4 votes to update some functions to explicitly allow null (going to round two, you get 1 more vote each, and 2 which drop out because they either didn't provide a second choice, or selected "Don't Mind")... also, while I have counted them, 7 people didn't enter a name, or entered "N/A"... and obviously this vote only helps me setup the RFC, it will be the RFC that will be the official record of who voted for what. Craig
