Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103674 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36266 invoked from network); 3 Jan 2019 12:48:53 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 3 Jan 2019 12:48:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1547112103; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=VLv6eXmePFSTOcKcIn715W N8A/lEqF9/sY0o8Dj/fWc=; b=XAYxS+eqtPm5FQ2qcyCrxEfOMBncvyYhBvpenQ BU1pOnU8JuahbsHOTxchEQn5XAmcbDyLThM2oXSSF+14eHM3txxKI3rkVx69QYj6 3XPTXAoer6UgLv9wFMPUc6aLnCZOJklfS9V2PlBjiZbArxddkX9Mv/FGB99s+8Kb 9o//s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=sMla1WgYrjSpS+ZfyseYnSE44xeXQKCr62hIMw1NDHDxTk8c4ddUOPkw1Gkc7S jMydnfki5C3vqkm24lCc71OPjK+qKWRa/IprIz/hU5yciB/Ym/PE9oNaPXUVIh5f BUBsXwV/UzufhX5+aPCLEC12DloE4X+rL9EN2RoM+xnCs=; Received: (qmail 19739 invoked from network); 3 Jan 2019 09:21:43 -0000 Received: X-TurboSMTP-Tracking: 4771840430 X-Gm-Message-State: AJcUukdEvHNkhcgrUdCCAivy4/kiDUTw4FGczXaU43i6CdejY+OPmCy1 DMn7dXAGvhn+d2+cEJpVNYpv6zU6KeSencp3K+M= X-Google-Smtp-Source: ALg8bN5gWNGDCrZKbZEj1Ihapm3kVW9k82uyw84d3D3Fk3wbkekVOVi+Rel7ni8h6zQgS3VFG6Y6aU0/DbMJNlOg4zw= X-Received: by 2002:a37:a211:: with SMTP id l17mr42926689qke.30.1546507302912; Thu, 03 Jan 2019 01:21:42 -0800 (PST) MIME-Version: 1.0 References: <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de> In-Reply-To: Date: Thu, 3 Jan 2019 11:21:31 +0200 X-Gmail-Original-Message-Id: Message-ID: To: Nikita Popov Cc: Stanislav Malyshev , "Christoph M. Becker" , PHP internals Content-Type: multipart/alternative; boundary="0000000000006ec99d057e8a4ad9" Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting From: zeev@php.net (Zeev Suraski) --0000000000006ec99d057e8a4ad9 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov 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 --0000000000006ec99d057e8a4ad9--