Victor-Nicolae Savu

I strongly disagrre with the resolution of this issue. Here is my reasoning: The whole point of `unsafe` declarations of traits or functions is to prompt the user to read...

What I am saying is that the responsibility for satisfying a contract should be advertised using `unsafe`. I am not saying the current library does something that is not sound,...

I would also be interested in finding out the status for this PR. @bubenkoff and @olegpidsadnyi in your opinion, what would be the remaining steps to finish this pull request?

@vodik > added that hook implementation as a separate pytest plugin Is your pytest plugin available anywhere, just so I can try it out? Do you plan on maintaining it?...

First off, thank you so much for this awesome library! I was hoping I can contribute my experience with `asyncio`. @olegpidsadnyi sad [here](https://github.com/pytest-dev/pytest-bdd/issues/223#issuecomment-331870328): > this means pytest-bdd has to depend...

@LegNeato Thanks for the quick reply! I quickly went through all of the open items before posting just because I was really expecting to see this issue :) I hope...

I tried looking into rolling my own macro for generating the necessary fields and found a few things that I wanted to share in case you or someone else has...

I had an idea how to just make `#[derive(GraphQLObject)]` and `#[graphql_object])` work together, but the implementation depends on rust-lang/rfcs#1210 (or rather on `#![feature(specialization)]` in nightly). Here is the general design:...

The downside of the design in [my comment above](https://github.com/graphql-rust/juniper/issues/553#issuecomment-612423320) is that `impl GraphQLData` becomes necessary even for cases where users don't want to expose some (or any) of the fields...

@jmpunkt This sounds great as well! The design space for this problem seems bountiful. > However, this could require to remove non-async code first, because we can not distinguish between...