Fix wording on Leaf Field Selections

[iglosiggio]

There's no other reference to "result types" on the specification and the same idea is given the name "return type" on IsValidImplementation, SameResponseShape and ExecuteSelectionSet.

As an aside: Should this wording be changed so field selections are forbidden for NonNull scalars and Lists of scalars but required for NonNull Objects and lists of Objects?

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: iglosiggio / name: Ignacio Losiggio (315c94efe7add16a478faf78d04eec6e18d805ab)

[netlify[bot]]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	315c94efe7add16a478faf78d04eec6e18d805ab
🔍 Latest deploy log	https://app.netlify.com/sites/graphql-spec-draft/deploys/6261b6ad24592800086113c4
😎 Deploy Preview	https://deploy-preview-940--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[iglosiggio]

Also, this change might be completely wrong if the idea is that the result type of something that has [Thing] or Thing! as it's return type is Thing.

If that's the case it would be nice to write this distinction explicitly in the spec.

[benjie]

I can see why "result type" was used here - "return type" is used for fields to dictate what can be selected on them, the "type" of the selection set is a related but separate concept.

If we look at the "CompleteValue()" algorithm we can see that it removes all the wrapping types before deferring to ExecuteSelectionSet(). Inside ExecuteSelectionSet() itself, the type is referred to as objectType - and we can see that CompleteValue handled the resolution of the abstract type (interface/union). The part of the spec you've highlighted seems to be referencing the unwrapped, but not abstract-resolved, type on which the selection set is valid. From a quick scan over the relevant parts of the spec, I cannot see that a name was ever attributed to this concept (except where you highlight, implicitly). Using "return type" or "field type" doesn't feel right because selection sets can also be defined by named fragments which have a "type condition", or by inline fragments which optionally can have a "type condition" too. Using "type condition" directly doesn't feel right because inline fragments don't need a type condition (they have the implicit type they inherit from the parent selection set, or field).

Anyway, this is a bit of a ramble without a conclusion. I agree some attention should be paid here; probably, as you say, a definition of the term "result type" is all that's needed.