Christoph Herzog

After some thought, I do think it makes sense to be inclusive here and support all the possibilities outlined by LegNeato. While I personally I am not a big fan...

I don't think we'll be able to fit `!Send` futures into the design, even with a feature. Things are already a bit messy with `GraphQLTypeAsync` layered on top of `GraphQLType`...

> As for me the best solution would be to have juniper being Send-agnostic I agree, in theory. In practice I think it's impossible right now. > Would you be...

> There is no sync/blocking calls in our case. Ah I misunderstood the problem, yes of course it makes sense in this context. What I don't understand is why the...

I'm closing this for now. The problem is on my radar. Feel free to continue discussion in the main async issue ( #2 ).

@nWacky good news, I think I might have found a way to do this reasonably well.

The derive assumes a `backtrace` field to hold a `failure::Backtrace`. The only sees tokens, so it can't check that the type of the field is something other than that. I...

I like the `source: err` syntax. Together with adding `Record::source()` this would also enable attaching an error to all the macros, and prevent clutter. The ability to log an error...

I thought a missing `Send` bound on the `Error` could be a problem for async loggers that ship the record to a different thread. But then I noticed that `Record`...

What's the status here? Anything that can be done to move this forward?