Question mark sn

[twof]

!!! IMPORTANT !!!

Please Read https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md before creating a Pull Request.

[benjie]

Some initial comments.

[benjie]

I think you want to delete this semantic block

[benjie]

This is really confusing; I think delete the Type : Type block above, and instead have:

Suggested change

	Type : Type ?
	- Let {nullableType} be the result of evaluating {Type}
	- Return {nullableType}
	Type : Name ?
	- Let {name} be the string value of {Name}
	- Let {type} be the type defined in the Schema named {name}
	- {type} must not be {null}
	- Return {type}
	Type : ListType ?
	- Let {itemType} be the result of evaluating {ListType}
	- Let {type} be a List type where {itemType} is the contained type.
	- Return {type}

[benjie]

The type system should be valid without reference to documents; support for SDL is optional.

[benjie]

Suggested change

	In docuements with a `@SemanticNullability` directive, input types are unaltered in
	terms of syntax. Unadorned types still represent nullable input types.
	In documents with a `@SemanticNullability` directive, input types are unaltered in
	terms of syntax. Unadorned types still represent nullable input types.

[benjie]

Wait so unadorned is nullable on input but non-null on output? What about if we add something like struct in future that allows the same composite type to be represented on both input and output - you're saying that the input field is allowed to be null, but when it's presented through output it would cause a non-null error to be raised?

@semanticNullability

struct Struct {
  nullable: Int?
  semanticNonNull: Int
  strictNonNull: Int!
}
type Query {
  identity(struct: Struct): Struct
}

query {
  # Valid input since unadorned is nullable on input?
  identity(struct: { nullable: null, semanticNonNull: null, strictNonNull: 0 }) {
    nullable
    # Identity produces error here?
    semanticNonNull
    strictNonNull
  }
}

[JoviDeCroock]

Should we extract document level directives to a separate spec PR, it seems to be lumped in here but sounds like a meaningful addition in the grander scheme either way

[twof]

Yeah truthfully we could also do no null propagation mode as it's own PR as well.

[benjie]

These should indeed be separate PRs 👍