-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow leading zeroes in numeric literals in Proposal A #46
Comments
Here's the second example: https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_and_leading_zeros.html That was I think the only motivation to currently not support it. I'll document that. As always, happy to discuss :) |
I think that classic octal notation with leading zero is highly confusing for many modern users. I think that there's no reason to forbid leading zeros. My implementation fails to parse them right now, but I tend to consider it a bug. But maybe it's wise to forbid leading zeros explicitly. |
Strongly disagree, I think leading zeros should be an error, particularly as they are in JSON proper. There is no benefit to allowing them, they add nothing, except confusion whether this represents octal notation or not. |
@danielaparker Great point about leading zeroes not being valid in JSON. Case closed? |
If we say we don't support leading zeros for Proposal A, then we would have our first case where we advocate for not supporting something while the consensus offers a result. |
You could always use your prerogative as owner of this site to say a resounding no! to the consensus on this:-) My own view is that the representation of numbers shouldn't differ from ECMA-404. Moreover, most of the JSONPath implementations lack a formal grammar, so it can be hard to tell whether a "feature" has been intended or merely reflects absent validation. For instance I doubt whether any implementation intended to support octal notation for array indexing, as some have. More likely the unintended consequence of using a general purpose |
I tend to share this point of view. I'd like to mention that some implementations allow using JSON object literals. Now let's remember that JSON scalars are also valid JSON documents; so maybe it would be convenient just to delegate JsonPath scalars to JSON spec? I mean, we can just use strict JSON syntax subset for defining JsonPath literals, including:
|
@remorhaz Agree that wherever possible a formalization of JSONPath should refer to existing specifications. |
Just to call out a limitation to that suggestion: we would have to separately support strings with single quotes. Some implementations even support arrays of strings with single quotes. |
Dark ages of JsonPath have ruined my beautiful idea, alas. But I still think that we should keep as close to existing JSON spec as possible; something like |
Agreed.
I think so, since implementations will want to use an existing JSON parser for parsing JSON values. |
The JSON spec for numbers disallows leading zeroes. I'm tending towards making leading zeroes a syntax error. (This will also allow implementations to add octal support as a strict extension of Proposal A if they choose to.) |
Looking at https://cburgmer.github.io/json-path-comparison/results/filter_expression_with_equals_number_with_leading_zeros.html makes me wonder if the rational for not supporting this in Proposal A was to allow for octal notation to be added in future.
It would be good either to allow leading zeroes or document the rationale for not supporting this.
The text was updated successfully, but these errors were encountered: