Hi, On Sun, Jan 11, 2015 at 7:07 PM, Paul Dragoonis <dragoo...@gmail.com> wrote: > > I feel if we need to make a minor BC break to get this in, then go with it > for PHP 7. > Yes, it's proposed only for PHP 7 as declared in the RFC
> I do think that if it's possible for you to detect when users supply this > invalid float input that you would throw an informative exception to help > people with the transition over to PHP7. > Let's first show an example and make clear what the whole thing: http://3v4l.org/2D72Q As you can see, the first type (07, 0xff, .1 and -.1) examples are really inconsistent and give a different results if there are in the array (error) or as a scalar. This seems like an obvious bug. The type 2 is consistent. The only problem is that such number format does not conform to RFC 7159 where the number is specified in https://tools.ietf.org/html/rfc7159#section-6 : number = [ minus ] int [ frac ] [ exp ] frac = decimal-point 1*DIGIT As you can see there is required a digit after decimal point... In this case we have a non conforming parser which is not right IMHO. About the special error messages. I could add a new error codes to identify these problem. However I am not sure that the current json error codes gives a useful information that would help with migration. I plan to look on error reporting later and create a different RFC if this one gets in. I have got an already implementation for bison locations in my testing scanner and parser ( you can see some logic in https://github.com/bukka/jso/blob/master/src/jso_parser.y#L160 ) that I used as an inspiration for jsond. The idea is to provide full reporting that includes location where the error is (line and column) and possibly text sample near to the error as well deeper identification of the error. It's not just this where we can give more info about the cause of the error. There is still some work and testing that will need to be done before I propose it however. Cheers Jakub
