Hi! > 2. Even if somebody is using this functionality, the only thing that's > going to happen is that their number display switches from 1,5 to 1.5. > That's a minor UX regression, not a broken application. It's something > that will have to be fixed, but it's also not critical, and for a legacy > application one might even not bother.
If this is part of a data pipeline, the difference between 1,500 and 1.500 can be huge (about 1000 times ;). With luck, there would be unit tests, so instead of broken bank account we'd have broken unit tests, but we all know how unit test coverage tends to lag behind... Number formatting difference may be a funny quirk in an average website context, but could be absolutely disastrous in scientific or financial application context. > I think we should just put this to an RFC vote. We regularly have these > types of discussions, and people just disagree about level of > anticipated BC break relative to benefit of the change. I do not object to the RFC vote. What we're doing now is something that comes before the vote - laying out arguments for and against it. I think that'd be prerequisite to having an informed vote. I don't think this change would absolutely ruin PHP if voted in, but I think I'd vote against it, given the arguments laid out so far. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
