Hi, I’m Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 83. Today I’m talking with George Peter Banyard, about another tidying up RFC, George, would you please introduce yourself?

Hello, my name is George and I work on PHP in my free time.

Excellent. I was just talking to Larry Garfield, and he was wondering whether you or himself, are the second often guests on this podcast, but I haven’t run a stats. But it’s good to have you on again. Following on for from other numeric RFCs, so to speak. This one is titled deprecate implicit non integer compatible floats to int conversions. That is a lovely small title you have come up with.

Yeah, not the best title.

What is the problem that this RFC is trying to solve, or rather, what’s the change that is in this RFC is trying to solve?

Currently in PHP, which is a dynamic language, types are not known at the statically at compile time, so it’s so everything’s mostly runtime. And most type conversions are relatively sane now in PHP 8, because like numeric strings have been kind of fixed. But one last standing issue is that floats will pass an integer check, without any notices or warnings. Although floats, don’t usually fit in integer will have like extra data which can’t be represented as an integer. For example, they can have a fractional part, or they can be infinity, or not a number if you divide, like infinity by infinity, or 0 over 0 or other things like that.

These are specific features of floating point numbers on computers?

Yes.

Is there any prior work that is RFC is building on top of

It builds up on top on the saner numeric string RFC, because it tries to like make the whole numericness of PHP, as a concept better and like less error prone, but in essence it’s mostly self contained. If you use a floating point number, were you should be using an integer. If the floating point number, is considered an integer because it only has like decimal zeros, and it fits in the integer range, then you’ll have like no error. So if you use 15.0 as an array key, it gets converted to 15, you’ll get don’t get any error because it’s like well it’s just 15 like it doesn’t mind. But if you do 15.5, then you’ll get like a, like a deprecation notice which will tell you it’s like, well, here’s the key gets implicitly converted, you should be aware of this because if you use 15 somewhere else, you’d be overriding the value.