Christoph Herzog

I guess the only reason for it's existence would be that you can't use a type as context in the macros that isn't intended to be used as a context....

I don't see a reason to ever add methods on context. More state keeping or functionality would be added to the `Executor`. There is a consideration with futures support though:...

> but why `Clone`? That's a necessary result from concurrency/parallelism. We'll need to clone the Context often. You could still use a single DB connection per query by wrapping it...

@petoknm great that you want to help out, I would hold off on this for now though until I publish my async/await branch and we have a clearer picture of...

This definitely makes sense, and I have very much wanted type safe look-ahead myself previously. When thinking about this a few months ago I came up with a slightly different...

Ah, I just noticed that this can not work at the moment: it would require GAT (generic associated types) to be implemented, since the lookahead type contains a lifetime...

> Having UserLookahead::best_friend return an Option is also a minor inconvenience True. I actually think your approach is better. We can always return the lookahead type and add a `walk()`...

I actually think your approach is way more clever/elegant, due to the type machine style of `Walked`/`NotWalked` and not requiring a custom struct for each object type. The downside is...

Mhm, I know some other libraries that have explicitly rejected this functionality as a built-in, since it goes a bit against the purpose of GraphQL and having this built in...

@LegNeato do you know of Graphql.js supports this?