Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109278
MIME-Version: 1.0
References: <CAH5C8xVoH-OmApcSF59eiUZye_aME1xiFs=umXEXLEG+pnjs8Q@mail.gmail.com>
 <CANS-=pdqvmsYXTLHHvm6VSdS+k0_q9QLKYV_oodH+cOEPjK8nw@mail.gmail.com>
In-Reply-To: <CANS-=pdqvmsYXTLHHvm6VSdS+k0_q9QLKYV_oodH+cOEPjK8nw@mail.gmail.com>
Date: Tue, 24 Mar 2020 19:41:28 +0100
Message-ID: <CAFPFaMKmrk_94wixE231x155RghR+ta2dmQu=VCccW9xHaNJ7A@mail.gmail.com>
To: Lynn <kjarli@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000d162f05a19e1ae0"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast
From: george.banyard@gmail.com ("G. P. B.")

--0000000000000d162f05a19e1ae0
Content-Type: text/plain; charset="UTF-8"

On Tue, 24 Mar 2020 at 11:03, Lynn <kjarli@gmail.com> wrote:

> Hi,
>
> This is a great RFC! Just one minor thing.
>
> > Outputting floats as strings in locales which change the decimal
> separator will have a slightly different output. In our opinion, the
> backward compatibility break won't be serious in practice
>
> In my opinion, this will be huge. I can't trace back where the thousands of
> possible conversions are used in legacy software. There's a variety of
> custom format functions, sprintf implementations, string casts, and
> number_format usages. Would it be possible to trigger a warning or
> deprecation when using a locale that would have a different result from
> what the new result will be? If I'd use a locale that results in `3.5`, I
> don't need a warning. If I use a locale that results in `3,5`, I would like
> to see a warning of sorts so I can fix this before untested legacy code
> will seriously break data exports.
>
> Regards,
> Lynn
>

We are not saying that this won't be prevalent,especially in legacy code,
however, IMHO, this is not a serious issue as it is only a matter how one
character is displayed to end users.

As said by Christoph we did not consider a deprecation warning due to the
performance impact this would lead to as float to string conversions are a
common operation.

The idea of a temporary INI setting which warn about these conversions
is an interesting idea, but I personally would rather not introduce one.
Moreover, with a temporary INI setting how long would it last, one minor
version, one major version? Something in between the two?



On Tue, 24 Mar 2020 at 11:15, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I'm obviously in favor of this proposal.
>
> Only really comment I have is on printf(): You're right that we have %f and
> %F to toggle locale-sensitivity, but the %e, %E, %g, %G formats are always
> locale-sensitive. It might make sense to introduce locale-insensitive
> variants of those, especially considering that %G is considered the
> "standard" floating point format. Internally we support %H for that, so we
> could expose that... (Alternatively, locale-sensitivity might be removed
> for e/E/g/G.)
>
> Regards,
> Nikita


*sight* I was not aware of this issue ...
Personally, I would prefer that %e and %E are not locale aware as they
are meant to represent a standard notation. This would then mean that
%g is locale aware as %f is and %G is not because %E and %F are
not locale aware.

But I'm open to suggestion considering this edge case.

Best regards

George P. Banyard

--0000000000000d162f05a19e1ae0--