Define matching for simple integers, leave others up to implementations#933
Define matching for simple integers, leave others up to implementations#933
Conversation
aphillips
left a comment
aphillips
left a comment
There was a problem hiding this comment.
I agree with removing the JSON reference, but we don't need to get carried away perhaps?
aphillips
added
functions
|
(chair hat ON) We approved fixing this text in the 2024-11-11 call, so this is on the fast track. Group members should weigh in if they have comments. Note that I require two approvals to merge, per process. |
aphillips
left a comment
aphillips
left a comment
There was a problem hiding this comment.
I think this is now fine.
I note that the match instructions have this:
If the value of
keymatches the productionnumber-literal, then
The number-literal production handles fractions and exponents. The WG consensus is not to solve this just now, but really... it's goofy to allow (in fact, require checking for) keys like 123.456 and 1.23e7 but not define a match for (some of) them. 'Nuff said. This PR accomplishes the goal set out for it.
|
@macchiati Can I get a review of this? I need two to merge. |
aphillips
requested review from
catamorphism,
echeran,
gibson042 and
mihnita
|
@macchiati Fixed. |
3 participants
More explicitly defines numeric matching for when it's well-defined, and when it's not well-defined.
Leaves values beyond non-negative integers as implementation-defined, and replaces the JSON reference with the
digit-size-optionABNF rule, as it's a better fit.