Re: Inconsistent float to string vs. string to floatcasting

Hi, Am 03.01.2019 um 10:21 schrieb Zeev Suraski:

On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

It's usually the other way around. The current behavior is prone to breaking integration code, because data interchange layers generally do not expect floats to use comma separators. The reason why things don't break quite as terribly as they could is that PHP has introduced a number of workaround over time, as these issues have been reported. That's why you usually don't run into this when inserting float values into a DB query, at least when using prepared statements. This issue is not handled everywhere though (one recent example I remember is passing floats to bcmath) and I don't think that introducing more of these special cases is how we should be approaching this problem.

Again, I'm not disputing that the current behavior isn't desired. I am disputing that it's a "no big deal" to change it 20+ years after the fact, and I am disputing that while many may not be fond of this behavior - they can still have code that has grown to rely on it over the years. I do think that if we do decide to change it, it should be while providing users a long-term (and probably permanent) language level way to keep the current behavior. Yes, it's against our motto - but then, so is such a widescale compatibility breakage without an easy forward path that does not involve a full line by line code audit.

Would it be possible to write a patch where every float-to-string-conversion that changes the representation because of the locale-setting, would produce a DEPRECATION or NOTICE or similar? The conversion output stays as it is today. Then people could run that patch against their own private projects. Or run against most popular 100 PHP Github projects. Run against 1000 random PHP projects from Github. Or create a specific PHP version that could run on Travis-CI or so... Currently there is a lot of guessing about the potentially affected libraries and projects, maybe it's better to measure. Then we get numbers of how many affected projects there might be. Maybe it's a huge problem, maybe only 0.001% of the projects are affected, and if they are affected, most likely it's considered a bug, not "intended behaviour". Nobody should rely on the current behaviour, best practice is to use number_format() if needed I think. If such a DEPRECATION/NOTICE would be emitted in 7.4, 8.0, and 8.x, then people have many years to fix it before the change finally is done in 9.0 or 10.0. We don't have to hurry, this might be a feature with a long period of DEPRECATION/NOTICE, potential bugs can be fixed during the years, before the final change happens. If there are really huge problems that we see during those years (but didn't see while measuring), thousands of developers complaining, in the worst case the change could be reverted. We should measure first, and then hopefully fix strange behaviour of PHP in the long run. Michael