Re: JSON float number as string

Hi, After bit of thinking I realised that it will be better to go with RFC and created an initial draft https://wiki.php.net/rfc/json_numeric_as_string . The thing that there are users asking for similar functionality for ints which is a bit controversial so it's better to have a RFC for that and also let people decide about the proposed version. Please don't comment on it till I put it under discussion (it's not completed yet). On Wed, Apr 1, 2015 at 8:07 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: > Hi! > > > The encoding was just about re-using it. I wouldn't probably propose > > such constant if it was just for encoding (the main purpose is decoding > > though). I just thought that it could be a good idea to have some usage > > for encoder if it's added. It seemed to me better than just ignore it > > completely for encoder. What do you think? > > I'd have encoder to ignore it. I will add a voting options for that to the prepared RFC. > > I didn't mean it for json_encode ( apology for that as it might have > > seemed that is related just to json_encode). I meant it just as "a sort > > of" bug for json_decode as we loose information without giving user any > > way how to prevent it or at least some note in documentation about that. > > It's not actually a bug - as I said, nobody who knows anything about how > computers do numbers expects exact representation of floats. That said, > ability to *somehow* accept numbers which don't fit current precision > may be useful in some corner cases, especially when you are > interoperating with systems with different number sizes. As the old > principle goes, be liberal in what you accept and conservative in what > you produce. json_decode() option would fit this principle well. > > I still think that this is not just a useful feature. The thing is that a user has no way to get complete information from the supplied json. The json is valid for any float value (there are no limits on precision in the spec) and we don't allow to keep that information. That's a problem and it doesn't matter if we call it a bug or something else! Cheers Jakub