Lee Byron

Marking this as Needs Champion. I still think this is an interesting RFC, but it needs work to progress.

What's the effect on the execution section?

Ok, I took a look at Execution: I believe the key parts are [`ExecuteField()`](https://spec.graphql.org/draft/#sec-Executing-Fields), [`CompleteValue()`](https://spec.graphql.org/draft/#sec-Value-Completion), and [`ExecuteSelectionSet()`](https://spec.graphql.org/draft/#sec-Executing-Selection-Sets) (which calls `ExecuteField()`) `ExecuteField()` is passed both a _fieldType_ and a set of...

Also there is the whole section on [Handling Field Errors](https://spec.graphql.org/draft/#sec-Handling-Field-Errors). We'll definitely need to clarify what we mean by "field type" in this section and make an explicit reference to...

> Is GraphQL.js intended to be a 1:1 representation of the spec? If not, is are my changes to the spec in the right place The goal is for it...

I think my main issue with the list nullability operators is their use of colon. That makes sense given the idea of providing a direct type annotation, but I find...

Can you share an example of what that might look like? I thought the case you described is already possible, but I may have misunderstood Right now I don't believe...

Grammar for that might be something like: ``` Nullability : - ListNullability NullabilityModifier? - NullabilityModifier ListNullability : `[` Nullability `]` NullabilityModifier : one of `!` or `?` ```

Elsewhere we do use validation to define clearly incorrect statements as invalid, so that seems like it would make sense for that operator as well

This is probably the right direction - I need some time to read and review (and this is definitely worth a WG discussion). Though one point of clarification for the...