On the other hand, significant breakage of 10 years-old APIs with not even release notes...
Well technically I believe it was done to unify argument parsing, but so far so good.
> to make it behave more coherently/consistently.
except this made all argument parsing (and especially this function) less coherent and consistent with PHP-the-actual-language: in PHP userland code, a string in a numeric concept will be implicitly converted to a number (to 0 if it is not prefixed by digits). This function used to behave coherently with PHP itself, as a language. Now it doesn't anymore. So all built-ins behave one way, the language itself behaves in the opposite way.
> It was documented
Not really, there was a note indicating plenty of shit broke (and it was ambiguous, the note says things about passing in incompatible parameters, but as far as PHP-the-language goes strings are compatible with floats), not listing functions which broke and in which manner.
With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways).
Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.
What "these few"? As far as I know there is no list of the functions impacted by the change, how do you define that there's just a few versus not just a few of others?
> but that would have messed up a lot more userland code than this change did.
Because ponies? Where does that arbitrary and unsupported assertion come from exactly?
> I think it was the most pragmatic way of dealing with the issue.
Why? And why was it an issue in the first place?
> The previous behaviour was undefined and completely undocumented
The previous behavior was implementation-defined (as pretty much all of PHP is) and had been stable for a decade. And as I noted above, it was also coherent with userland behavior of PHP when dealing with strings in numerical contexts.
> Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.
Which, for all intents and purposes, mean they're compatible with floats in most numeric contexts.
Why was it pragmatic? Why was it an issue? There was inconsistency in the ways that functions handled parsing, and many people didn't want that feeling it made it harder to code correctly/consistently, thus it was an issue (part of the greater issue of inconsistency across a number of aspects of PHP). For others it wasn't an issue, which is why a pragmatic solution is the best that could be hoped for, not everyone would agree/like the outcome whatever was done (or not done). I can't see any other way of taking the language forward whilst causing minimum impact to users, which is why I (not you) think it was the most pragmatic way.
Every piece of code we write is "implementation-defined", including the bugs. It wasn't coherent with most other function implementations. Users couldn't reliably treat functions in the same way. I agree it wasn't coherent with numerical operations, but to get that consistency you would have to change a whole load more functions, and you would get many more complaints like this one.
"For all intents and purposes" - I think this discussion (and the many others that have featured on HN talking about similar issues of the weakly typed nature of PHP, such as == vs === ) show that it there are real world consequences to treating strings and numbers as compatible.
On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One could therefore expect the relevant coercitive calls to be performed as they would usually be.
> it's the very first incompatible change listed
It is very ambiguously worded: the clause states functions will return NULL when passed incompatible parameters, but in all of PHP's userland code strings are very much compatible with floats. I would therefore submit that — in the context of being a user of PHP — the clause does not apply to this case as the value passed in is absolutely compatible with parameter expectations.
What should a lisp implementation return when (car '()) is evaluated? How does a arbitrarily chosen return value differ from a undefined behavior?
Is "" -> 0 a standard conversion in PHP? I get it if we consider the groups (String, +) and (Float, +), but 0 is hardly the standard identity value.
In it being defined, don't you think?
> Is "" -> 0 a standard conversion in PHP?
Erm... yes? `(float)""` returns that, `"" + ""` returns that, `0 + ""` returns that, and so do `intval('')`, `(int)''` or `floatval('')`. More generally, http://www.php.net/manual/en/language.types.string.php#langu...:
> When a string is evaluated in a numeric context, the resulting value and type are determined as follows [...] The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero).
> 0 is hardly the standard identity value.
0 remains the standard and defined numeric value of an arbitrary string not prefixed with numeric data in PHP.
You know, I didn't actually know that. Thank you for enlightening me.