You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there are some language ambiguities and underspecification for lexing numbers which each implementation has handled slightly differently.
Because commas are optional and white space isn't required between tokens, these two snippets are equivalent: [123, abc], [123abc]. This may be confusing to read, but it should parse correctly. However the opposite is not true, since digits may belong in a Name, the following two are not equivalent: [abc, 123], [abc123]. This could lead to mistakes.
Ambiguity and underspecification enter when the Name starts with "e", since "e" indicats the beginning of an exponent in a FloatValue. 123efg is a lexical error in GraphQL.js which greedily starts to lex a FloatValue when it encounters the "e", however you might also expect it to validly lex (123, efg) and some implementations might do this.
Further, other languages offer variations of numeric literals which GraphQL does not support, such as hexidecimal literals. The input 0x1F properly lexes as (0, x, 1, F) however this is very likely a confusing syntax error. A similar issue exists for some languages which allow underscores in numbers for readability, 1_000 lexes a 1 and _ but fails when 000 is not a valid number.
Description of the feature
Currently there are some language ambiguities and underspecification for lexing numbers which each implementation has handled slightly differently.
Because commas are optional and white space isn't required between tokens, these two snippets are equivalent:
[123, abc]
,[123abc]
. This may be confusing to read, but it should parse correctly. However the opposite is not true, since digits may belong in a Name, the following two are not equivalent:[abc, 123]
,[abc123]
. This could lead to mistakes.Ambiguity and underspecification enter when the Name starts with "e", since "e" indicats the beginning of an exponent in a FloatValue.
123efg
is a lexical error in GraphQL.js which greedily starts to lex a FloatValue when it encounters the "e", however you might also expect it to validly lex (123
,efg
) and some implementations might do this.Further, other languages offer variations of numeric literals which GraphQL does not support, such as hexidecimal literals. The input
0x1F
properly lexes as (0
,x
,1
,F
) however this is very likely a confusing syntax error. A similar issue exists for some languages which allow underscores in numbers for readability,1_000
lexes a1
and_
but fails when000
is not a valid number.References
graphql/graphql-spec@09cdaec
The text was updated successfully, but these errors were encountered: