Should Schema.build_from_definition inherit fields from the interface?

[emilebosch]

Should schema with build_from_definition implicitly copy the fields over from the interface to the type? I.e. that I don't have to explicitly copy the field name under the student? If this is required should it then not raise an error for an incomplete implementation?

An SDL example to clarify:

interface User {
  name: String!
}

type Student implements User {
  grade: Int! 
  # Implicit `Name: String!`  ?
}

type Query {
  student: Student
}

type Mutation {
  name: String
}

However I see that in https://graphql.org/learn/schema/#interfaces, they explicitly include the fields. Shouldn't there be a warning then at least with build_schema_from_definition, that the type doesn't adhere to the interface?

[emilebosch]

Okay, I read up here that this degrades the readability of the schema. Which I agree with actually: graphql/graphql-spec#335 (comment)

See: #500 (comment)

TL;DR this proposal doesn't allow new use cases that were not already possible and degrades readability of schema in the name of writing less, which goes against GraphQL's guiding principles

However should the build_from_definition not BANG when I am not implementing that interface fully?

[rmosolgo]

Yeah, it makes sense to check for a resolver earlier on. I'm not working much on build_from_definition right now, but I'd welcome a PR for that!