Schema parser doesn't handle "&" when specifying multiple interfaces

[wravery]

If I'm reading the spec right, type definitions which implement multiple interfaces should have a & separator between the interface names and optionally before the first interface name for a single interface. The parser rule for implements_interfaces_opt in parser.ypp only expects whitespace.

[swolchok]

Makes sense, the schema definition language support was based off a proposal and hasn't been updated to reflect the June 2018 edition of the spec. I need to take a look at how much work that's going to be...

[felipecrv]

@swolchok how experimental is the schema support in parseFileWithExperimentalSchemaSupport()?

[swolchok]

It's not compliant with the June 2018 spec. It reflects the RFC as it was on the date when it was committed. https://github.com/graphql/libgraphqlparser/pull/45 added it based on https://github.com/facebook/graphql/pull/90 as it was on the day it was committed. I have an unfinished stack to port the changes made since then to libgraphqlparser; the major snag is that the object model for the libgraphqlparser AST (base classes + inheritance) doesn't really accommodate matching the graphql-js AST for schema things exactly because I would have to do weird things with multiple inheritance.

I'm a bit fuzzy on how widely used libgraphqlparser is. If there are a lot of people waiting for these updates, that might motivate me to dust off the stack sooner rather than later. :)

[felipecrv]

I'm a bit fuzzy on how widely used libgraphqlparser is. If there are a lot of people waiting for these updates, that might motivate me to dust off the stack sooner rather than later. :)

I'm writing a prototype thing that might be put into production... or not. I think the October 2016 spec (http://facebook.github.io/graphql/October2016/) is good enough for me.