Hi! > Regarding the decimal separator (aka. decimal point), the behavior of > casting float to string is inconsistent with casting string to float. > While the former regards the current locale, the latter always expects a > decimal point regardless of the locale. This breaks round-trips for > locales which use something else than a dot as decimal separator (e.g. > German, which uses a comma), for instance:
That may be inconvenient, but changing it now would be way worse IMHO. Ideally, system conversions would return well-defined result (locale as a global is a *horrible* idea which can only be explained by it's genesis in simpler times where most of the software was written to be run in one specific environment and user putting a pack of punch cards into the reader would only need them to be processed in one locale) and for configurable outcome you'd use functions that receive explicit parameters. > As for me, the question is not *if*, but rather *when* and *how* this > inconsistency should be resolved. Regarding the *when*, it seems to me If you mean that loading "0.3" from string would suddenly stop working in Germany, then never. If you mean that (string)0.3 would return "0.3" and not "0,3" in Germany, then again I'd say probably never, though very slightly less confidently. Those people who didn't want it already have code to deal with it, and those that wanted it would have their unit tests crash and burn and their data pipelines blow up. I think it's a very bad idea to change such things, which would create hundreds of year-persons of headache to anybody daring to upgrade. I understand it's a bad situation, but I think the right exit of it is to tell people that want predictable roundtrip results to use specific number conversion functions, and not exchange one mess to another, BC-breaking and havoc-wreaking, mess. I agree that the right thing to do would be to have (string)0.3 to always use dot and never use locale (did I mention I think global locale is a horrible idea?) but that ship has sailed. I don't see a use case that would be well served by breaking the BC now. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
