David Pedersen

@LegNeato what sort of future extensibility are you thinking of? I imagine adding methods to the trait would also be breaking change. I'm also in favour of deprecating it.

I'm not that familiar with futures, but why `Clone`? The app I'm working on has a context like this: ```rust pub struct Context { db: DbCon, // more things... }...

Makes sense. Seems to still be [early days for async in Diesel](https://github.com/diesel-rs/diesel/issues/399).

Hm true. I wonder what the implications would be to add that lifetime to `GraphQLType` so ```rust impl for User { type Lookahead = UserLookahead, ) -> ExecutionResult { //...

> Sadly not possible since the lifetime is not related to the type implementing the trait. Are you sure? I do something similar in [`juniper_eager_loading::EagerLoadChildrenOfType`](https://docs.rs/juniper-eager-loading/0.4.1/juniper_eager_loading/trait.EagerLoadChildrenOfType.html). That trait has a lifetime...

Why not just use a regular structured input type?

You could do something like this: ```graphql mutation { foo(pairs: [Pair!]!): Boolean } type Pair { key: String! value: String! } ```

This works for me ```graphql # Schema. You'll have to translate this into rust yourself but it should be pretty straight forward type Mutation { foo(pairs: [Pair!]!): Boolean! } input...

I'm wondering if https://github.com/graphql-rust/juniper/pull/782 hinder stuff like this?

> Using a different struct and using a custom From like trait to fill it in with the field from Context IMO this approach is fine. It might also make...