From 3a458c30299458322e4938992ce691096cac0ccf Mon Sep 17 00:00:00 2001 From: mjmahone Date: Thu, 5 Jan 2023 13:02:46 -0500 Subject: [PATCH] Updated RFC doc: explanation on required vs nullable --- rfcs/FragmentArguments.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/rfcs/FragmentArguments.md b/rfcs/FragmentArguments.md index 426dac663..faeec0780 100644 --- a/rfcs/FragmentArguments.md +++ b/rfcs/FragmentArguments.md @@ -286,6 +286,28 @@ fragment Bar($x: Int!) on User { } ``` +### Potential Alternative: Default Value indicates _required or not_, and `!` indicates _non-null or nullable_. + +If we were writing the language from scratch, I'd advocate for making _all_ +argument definitions without a default value to be required, regardless of their +nullability. If you want to make a nullable argument optional, you do so by +adding a `= null` to its definition. + +In short, if I define: + +``` +fragment Bar($x: Int) { number(x: $x) } +``` + +then `...Bar` would be **invalid**. + +However, that's not how operation variables, field arguments, directive +arguments or input object fields work today, no matter how much I might wish it. +For this RFC, I'm making the meaning of "required" and "nullable" for fragment +spread arguments the same as all other inputs, because doing something +_different_ would be more confusing IMO, even if that difference would lead to +unvalidated fewer foot guns. + ## Updated Validation: Overlapping Fields Can Be Merged Previously, fragment spreads didn't have to be considered as unique selections