On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov <nikita....@gmail.com> wrote:
> 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. > While you may very well be correct that some (maybe even most, not sure) people don't have the express intention of receiving this behavior - nonetheless, this is the behavior they've been seeing in the last 20 years. Many, arguably most developers code based on the behavior they see in practice. Whether or not they thought this behavior is sensible, once they saw this is the behavior in practice - it's likely that they relied on it. Of course, some may have been put off but what they saw and decided to use something else (e.g. avoiding setlocale() altogether) - but I doubt this is anywhere close to 100% of the developers. > 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. > I agree, but the real question is how many of those who are explicitly calling setlocale() are relying on this behavior - as the change we're proposing effects only them anyway. So while the fact those who are using setlocale() are likely a small minority is a given, the real question is within this subgroup - what's the breakdown of people relying on it. I'd argue that within that group, those relying on it are likely a majority, even if when they first bumped into this behavior they thought to themselves "Huh, that's funny, I didn't expect that.". Ultimately, their code now relies on it. There shouldn't be any developers who are using setlocale() and are relying on a behavior that never existed in PHP (which doesn't mean they don't exist - but I can't imagine they're a sizable subgroup let alone a majority). 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. > I agree here, it doesn't have to be on the "other side" like I claimed. It may still be easier in many cases, as at least fixing it on the PHP side would be quite difficult (again, involve a line by line code audit). > 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. Zeev
