Skip to content

Fix ambiguity about optional variables in non-null args #520

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.

Sign up for GitHub

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 2 commits into from
Jul 5, 2019
Merged

Fix ambiguity about optional variables in non-null args #520

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d155188
Fix ambiguity about optional variables in non-null args
leebyron Oct 2, 2018
4d73e50
Review feedback. Now hopefully with even less ambiguity!
Oct 2, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions spec/Section 5 -- Validation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1938,6 +1938,10 @@ A notable exception to typical variable type compatibility is allowing a
variable definition with a nullable type to be provided to a non-null location
as long as either that variable or that location provides a default value.

In the example below, an optional variable is allowed to be used in an
non-null optional argument (`optionalBooleanArg`) because it provides a default
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is ambiguous (optional variable or non-null optional argument?) and further muddied with the naming optionalBooleanArg (how is an optional argument non-nullable?)

Proposal:

In the example below, an optional variable is allowed to be used in an 
non-null optional argument (`booleanArgWithDefault`) because the
field argument provides a default value in the schema.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@leebyron I agree with @mjmahone. And also think we should remove optional from non-null optional argument.

value (`false`).

```graphql example
query booleanArgQueryWithDefault($booleanArg: Boolean) {
arguments {
Expand All @@ -1946,7 +1950,11 @@ query booleanArgQueryWithDefault($booleanArg: Boolean) {
}
```

In the example above, an optional variable is allowed to be used in an non-null argument which provides a default value.
In the example below, an optional variable (`$booleanArg`) provides a default
value (`true`) and can be used in a non-null requied argument. This behavior is
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: required

explicitly supported for compatibility with earlier editions of this
specification. GraphQL authoring tools may wish to report this is a warning with
the suggestion to replace `Boolean` with `Boolean!` to avoid ambiguity.

```graphql example
query booleanArgQueryWithDefault($booleanArg: Boolean = true) {
Expand All @@ -1956,10 +1964,5 @@ query booleanArgQueryWithDefault($booleanArg: Boolean = true) {
}
```

In the example above, a variable provides a default value and can be used in a
non-null argument. This behavior is explicitly supported for compatibility with
earlier editions of this specification. GraphQL authoring tools may wish to
report this is a warning with the suggestion to replace `Boolean` with `Boolean!`.

Note: The value {null} could still be provided to a such a variable at runtime.
A non-null argument must produce a field error if provided a {null} value.