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.

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

Conversation

leebyron
Copy link
Collaborator

@leebyron leebyron commented Oct 2, 2018

"Allowing optional variables when default values exist" wasn't very clear about what elements of the example were being referred to as optional/required or non-nullable. This minor rewrite attempts to resolve that ambiguity

Fixes #507

"Allowing optional variables when default values exist" wasn't very clear about what elements of the example were being referred to as optional/required or non-nullable. This minor rewrite attempts to resolve that ambiguity

Fixes #507
@leebyron leebyron added ✏️ Editorial PR is non-normative or does not influence implementation 🤷‍♀️ Ambiguity An issue/PR which identifies or fixes spec ambiguity labels Oct 2, 2018
@@ -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.

@@ -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

Copy link
Contributor

@mjmahone mjmahone left a comment

Choose a reason for hiding this comment

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

This is pretty clear to me now

@IvanGoncharov IvanGoncharov merged commit f18c922 into master Jul 5, 2019
@leebyron leebyron added this to the May2021 milestone Apr 9, 2021
@leebyron leebyron deleted the optional-var-ambiguity branch April 9, 2021 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤷‍♀️ Ambiguity An issue/PR which identifies or fixes spec ambiguity ✏️ Editorial PR is non-normative or does not influence implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incoherent description for default value in an argument
4 participants