Null-Only-On-Error / Semantically-Non-Null type (asterisk)

At a glance

• Identifier: #1048
• Stage: RFCX: Closed 2023-11-24T11:32:44Z
• Champion: @benjie
• PR: Null-Only-On-Error / Semantically-Non-Null type (asterisk)
• Related:
  • #1050 (Directive proposal for opting out of null bubbling)
  • #1065 (SemanticNonNull type (null only on error))
  • wg#1394 (True Nullability Schema)
  • wg#1410 (Strict Semantic Nullability)

Timeline

• Added to 2023-10-05 WG agenda
• Spec PR created on 2023-10-04 by benjie
• 3 commits pushed on 2023-10-04:
  • Add specification changes for Null-Only-On-Error type by @benjie
  • Add examples combining null-only-on-error with list and non-null by @benjie
  • Remove duplicate coercion for brevity by @benjie
• Mentioned in 2023-10 WG notes

---

This PR replaces #1046. Here's an updated description:

Inspired by @captbaritone's True Nullability Schema discussion (https://github.com/graphql/graphql-wg/discussions/1394) and following @fotoetienne's excellent talk at GraphQLConf and feedback on my resulting PR #1046, I am proposing that we introduce a new wrapper type, the "Null-Only-On-Error" type, represented via asterisk *. This new type walks the line between the default nullable types and the existing Non-Null type wrapper - it states that the value may only be {null} if a field error has been raised - i.e. it represents the "true nullability" of the field, whilst still acting as an error boundary to avoid null propagation.

Critically, this type would "evaporate" for legacy clients, appearing the same as a nullable field. (This is enabled via the includeNullOnlyOnError argument to the __Field.type field, which defaults to false.)

This is a much more complete RFC that #1046 was, and happily leverages a lot of the existing behavior of the spec.