I'm very sorry, I pressed the reply instead of reply all button, I hope this fixes it!
I agree that these cases can go horribly wrong. However, my reasoning is > the following: > - if a piece of code currently relies on locale-independence (e.g. > automated data exports) then this > change wouldn't cause any breakage since a workaround has already been in > place there (e.g. the > programmers use var_export() instead of casting) > - if a piece of code relies on the locale-dependent string representation > of floats then there will be > a BC break, sure, however I believe that code isn't very sensitive to the > change in the vast majority of the > cases since that data is for presentation purposes only. > I know it's for presentation purpose only, sadly it's not used for just presentation code. It's being consumed and parsed by automated imports that expect a format different than `3.5`, because that's how it organically evolved. Even when it was meant only for presentation, the consumer expected the `3,5` format and will keep expecting this until we notify them of a change (and then it will probably still take weeks before this is fixed on their side). A lot of code that I've encountered is stuff like: ``` $csv .= $product->getPrice() . ';'; // older code I've seen come by $product = get_product($$var5); $csv .= $product['price'] . ';'; ``` As much as I'd like to see this fixed and always give a `3.5`, sadly that's not the case if you use a different locale. Going through thousands of files to fix this, is not going to be an easy task, especially not as this is often old enough to not be usable by static code analyzers. > Or do you have other locale-dependent use-cases in mind? I am sure there > are some but I think the number of the situations where the change is > problematic is less than what it first seems. > No, this is the only issue I personally see with it. However, the impact could be severe enough to not be able to upgrade to a new PHP version in the foreseeable future, thus I would like to see an upgrade path, one that tells you where it would've gone wrong, instead of turning the behavior on or off. If I can gather the logs and thus find usages, I can pro-actively start fixing where this would go wrong. I'll take a performance hit over a breakage. Performance penalty would only have to apply if the locale is set to something we know will change the outcome. Maybe it turns out this is a small issue, maybe it's a big issue... I can't tell because it's either upgrade & break, or upgrade & work in the proposed scenario. Some breakage may take weeks to find out because scripts run periodically. I fully understand that you don't see this as a big issue, and I really wish I could say the same. I can't vote, so I can't change the outcome, please consider my use-case when moving forward, thanks! Regards, Lynn
