The Proposal Currently Known As Client Controlled Nullability: Syntax Naming

[twof]

At the same time we're discussing the naming of the proposal itself, we can reassess the naming the of the syntax. While the syntax currently known as required and optional designators used to simply change the type of the fields to which they were applied to the non-nullable and nullable versions of themselves respectively, they now have additional behavior.

If we choose the "assertion" framing for the proposal name, it would also probably make sense to choose the "assertion" framing for the syntax naming.

Update June 4th, 2022: Based on the results of this poll, "Non-Null Assertion/Catch/List Operator" is the winner, but I'll be substituting "Catch" with "Error Boundary" as Lee suggested. I'm still not super happy about any of the options for the list syntax, so I'll keep thinking on it.

[twof]

We've talked about calling ! "non-null assertions", but I can't find anywhere that a name has been suggested for ? or [] if we do that. I've selected "Catch" and "List Operator" for now, but I'm totally open to other names too that might better fit the paradigme.

[] in particular is a weird one since it doesn't do anything on its own, so some of the terminology like "designator" doesn't feel like it makes sense. I was thinking maybe "list introspection"?

[leebyron]

• ! - Non-null Assertion
• ? - Error Boundary
• [!] - We elsewhere call this "inner" so "Inner non-null assertion" and "Inner error boundary?

[leebyron]

Perhaps the collective set are "nullability operators" or "nullability assertions"

[twof]

Any thoughts on what you might call [] on their own? I'm trying to figure out what to name the AST node.

[benjie]

Empty "operator list" or "list operator"?

[twof]

Hello! It's been a while. The Client Controlled Nullability RFC is now winding down in favor of True Schema Nullability, so I'll be closing CCN related issues, PRs, and discussions. All further discussion should be rerouted to one of the following:
#1394
graphql/nullability-wg#39
#1410
graphql/graphql-spec#1065

Additionally, we're in the process of removing the CCN experimental flag from graphql-js.

TL;DR of the new proposal(s) is that instead of allowing clients to adapt to imprecise schema definitions, our new approach is to find ways to allow schema authors to provide the precision that's been missing. There are a few different approaches to that which you can read about in the discussions above. Apollo and a couple other schema authors are in the process of putting together experiments, so if you'd like to have input or beta test the new proposal(s), reach out to us either in the Nullability Working Group, or in the #nullability-wg channel on Discord.