Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103671
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 02 Jan 2019 21:31:24 +0200
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <CAJHtznwkU5nt3hPrE7f8X+cND3F6OMxTaFGBUZ6=Of_+rB0tsQ@mail.gmail.com>
References: <a7761c2f-5716-279b-d701-5f588b856277@gmx.de>
 <dbfae3d5-e317-f680-9fe6-240ab142d105@gmail.com>
 <94f5feb8-6589-3a0a-2849-7679cec1858c@gmx.de>
 <a0e50789-10c0-263d-f6a7-56486d7bb318@gmail.com>
 <CAF+90c-2ama6LBDY0xQKN1oPV-YMaY2==SSWk_hSstc40y9NWQ@mail.gmail.com>
 <CAJHtznzzBvx9Dc5YPGT6kU97doCj0O2FxGGjnTNh4Pv2-Pucxg@mail.gmail.com>
 <CAF+90c_i7802QYeBUkgyc81Yv2ASzSHYqxNrObcA+TxA_b_46A@mail.gmail.com>
 <CAJHtznwkU5nt3hPrE7f8X+cND3F6OMxTaFGBUZ6=Of_+rB0tsQ@mail.gmail.com>
Message-ID: <cd85258eed359237f88426ecc84838f4@gmail.com>
User-Agent: Roundcube Webmail/1.3.8
Subject: Re: [PHP-DEV] Inconsistent float to string vs. string to floatcasting
From: lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=)

On 2019-01-02 19:22, Zeev Suraski wrote:
> 1. I'm not sure what you mean "not many people use this"?  People don't
> convert floats to strings?

People don't format their floats using setlocale + echo. People use 
things like sprintf and number_format to get the right number of 
decimals, and many use number_format or even str_replace to change the 
decimal separator because setlocale has weird side effects (like the one 
being discussed).

On 2019-01-02 19:22, Zeev Suraski wrote:
> 3. I view a UX change as a big deal.  As we should in a language that 
> is
> very commonly used to create UI.

Then what about existing UI bugs? Thanks to this discussion, I found 
exactly one instance of setlocale in my whole PHP code base (used to 
format a printf nicely), and I also found a bug where "stringparam=$x" 
was ill-formatted because of this and produced a visible error in a 
generated image (although not critical and thus unnoticed until now). I 
was certainly not relying on this behaviour. It was just bad luck that 
the output (at least when I saw it – don't know about other users!) was 
”good enough” that I didn't notice the bug.

On 2019-01-02 19:22, Zeev Suraski wrote:
> 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.

It's reasonable to expect that a float (with known range) is a valid 
number in most programming contexts such as CSS (width: <?= $float ?>px) 
or HTML (input type=number value=<?= $float ?>) or JavaScript (var width 
= <?= $float; ?>). Using number_format to fix these would feel almost as 
bad as using number_format before every arithmetic operation.

Because of this behaviour, using setlocale will break many libraries 
which output floating-point values in any other context than 
user-visible text.

On 2019-01-02 19:22, Zeev Suraski wrote:
> With the fix HAVING to be in the other side, no less.

How so? If you send floats, you can format them yourself (and you 
certainly should, if they are locale-dependent!). If you receive floats, 
you can parse them yourself. No need to change ”the other side”.

-- 
Lauri Kenttä