On Tue, 24 Mar 2020 at 11:03, Lynn <kja...@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....@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
