Skip to content

Clarify 'Values of Correct Type' rule relates to literals #1118

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

Merged
merged 9 commits into from
Apr 17, 2025
15 changes: 13 additions & 2 deletions spec/Section 5 -- Validation.md
Original file line number Diff line number Diff line change
Expand Up @@ -1303,15 +1303,26 @@ fragment resourceFragment on Resource {

**Formal Specification**

- For each input Value {value} in the document:
- For each literal Input Value {value} in the document:
- Let {type} be the type expected in the position {value} is found.
- {value} must be coercible to {type}.
- {value} must be coercible to {type} (with the assumption that any
{variableUsage} nested within {value} will represent a runtime value
suitable for usage in its position).

**Explanatory Text**

Literal values must be compatible with the type expected in the position they
are found as per the coercion rules defined in the Type System chapter.

A {ListValue} or {ObjectValue} may nest additional Input Values, some of which
may be a {variableUsage}. The
[All Variable Usages Are Allowed](#sec-All-Variable-Usages-Are-Allowed)
validation rule asserts that each {variableUsage} is of a type allowed in that
position, and the [Coercing Variable Values](#sec-Coercing-Variable-Values)
algorithm will ensure runtime values of these variables coerce correctly, thus
we can assume the runtime value of each {variableUsage} will be suitable for
usage in its position.

The type expected in a position includes the type defined by the argument a
value is provided for, the type defined by an input object field a value is
provided for, and the type of a variable definition a default value is provided
Expand Down
Loading