Input Coercion for Non-Null states that field(arg: null) is illegal, but it's not about graphql-spec HOT 3 CLOSED

Whoops indeed. We were writing spec as we were deciding on whether null should be a keyword or not.

The reason we decided not to have null as a keyword was that field(arg: null) and field would be isomorphic and it felt a little weird to have two ways of specifying the same thing.

I think we have a few possible paths forward and I'm interested in your opinions on which we might follow:

1. Fix up the spec, leave things as they are, carry on.

2. Introduce a null keyword which represents the value null. Introduce this slightly odd isomorphism but allow null to be used as expected.

3. Introduce a reserved blacklist which the Name grammar cannot represent (or more conservatively the EnumValue cannot represent?), and include null on this list. This means there's no way to represent the input value null as is currently the case, but just makes field(arg: null) not even parse rather than do an unexpected thing.

from graphql-spec.

Strong vote for fixing the example. With arguments being unordered and having optional default values I don't see a reason for having an explicit null-type in GraphQL. A list of reserved words that are not going to be used in the future only because they have a meaning something in a different popular language makes no sense.

from graphql-spec.

I added some clarification to the example itself, but also implemented the conservative form of option "3" I described above in a12f6df. An EnumValue cannot be null to avoid this confusion.

from graphql-spec.