On Wed, Jan 2, 2019 at 6:22 PM Zeev Suraski <z...@php.net> wrote: > > > On Wed, Jan 2, 2019 at 6:11 PM Nikita Popov <nikita....@gmail.com> wrote: > >> On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski <z...@php.net> wrote: >> I don't expect this to be a particularly large issue for two reasons: >> >> 1. Not many people use this. I'm sure that there *are* people who use >> this and use it intentionally, but I've only ever seen reference to this >> issue as a bug or a gotcha. >> 2. Even if somebody is using this functionality, the only thing that's >> going to happen is that their number display switches from 1,5 to 1.5. >> That's a minor UX regression, not a broken application. It's something that >> will have to be fixed, but it's also not critical, and for a legacy >> application one might even not bother. >> > > FWIW, neither of these are very convincing for me: > 1. I'm not sure what you mean "not many people use this"? People don't > convert floats to strings? >
No, that's not what I meant. Of course, many people convert floats to strings. But the vast majority of them expect to get back a floating point number in the standard format. What I mean is that there are not many people who use float to string conversion with the express intention of receiving a locale-dependent result (and use a locale where the question is relevant). Those are the only people who would be (negatively) affected by such a change. > 2. Perhaps you meant they weren't proactively relying on this behavior, > which could be true - but it doesn't matter whether people were expecting > or otherwise desiring this behavior when they wrote the code. Whatever the > current behavior is - they adjusted for it, and ended up using it, > consequently relying on it. > As said, I'm sure there are people relying on this. What I'm saying is that the number of people who rely on float conversions to *not* be locale-sensitive is vastly, orders of magnitudes larger than the number of people who *do* rely on it being locale sensitive. The only saving grace is that this issue only turns up relatively rarely, because it requires you to explicitly call setlocale, as the locale is not inherited from the environment. Or more likely, you're not going to call setlocale, but discover this wonderful behavior because something else does for entirely unrelated reasons. > 3. I view a UX change as a big deal. As we should in a language that is > very commonly used to create UI. > 4. This could effect not only UX, but also integration code. You could > have PHP output feeding into something else - and suddenly, the format > breaks. With the fix HAVING to be in the other side, no less. > The fix doesn't have to be on the other side. Most likely you'd prefer to fix it on your side by explicitly formatting the float in the desired manner. 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. Nikita
