On 26 August 2025 19:23:20 BST, "Tim Düsterhus" <t...@bastelstu.be> wrote: >"Surprising changes" is not a meaningful term. Keep in mind that the behavior >of the function will need to be accurately documented and that folks need >something to work with to determine whether a report is valid or not when bugs >in the function get reported - which will inevitably happen.
I think there's a sliding scale of "strictness" of casts, with string to float probably the hardest to pin down. At one end, you have "purely lossless" or "symmetrical" - where (string)(float)$x === $x This would mean accepting '4' but not '4.0', which is probably not what users would expect. From there, you can add some "normalisation" - ignore insignificant zeros at start and end; perhaps also ignore leading and trailing spaces. Then you get alternative representations - most commonly, scientific notation like '2.5E10'. This hugely increases the number of inputs that result in the same output, e.g. '0.2E1' is yet another synonym for '2'. Then there are inputs which don't fully match the normal format, but are unambiguous - '.1', '1.', '+1', etc At the other end of the scale, there's the "best guess" approach that PHP's explicit cast operators use - (string)(float)' +4.2E1 bananas ' results in '42' And that's *before* we check the precision of the resulting interpretation, and how close the floating point value is to the target decimal. I'd really like something stricter than is_numeric but more flexible than ctype_digit; but exactly what it should do is a bit of a minefield. Rowan Tommins [IMSoP]
