Oliver Schulz

I think it may actually be the unthunk in `tailmemaybe(x::Tuple)` that results in that error, not the one in `Grads(IdDict(...))`.

It looks like for this to work, we'll need to overload a lot of functions like `x'`, `Adjoint`, `transpose`, `Transpose`, `diag`, `Diagonal`, `permutedims`, `permutedims!`, `Ref`, `Vector`, `Matrix`, `Array`, `collect`, `convert`,...

Ok, with FluxML/ZygoteRules.jl#17 this passes the Zygote test suit on my system now (incl. CUDA tests). In both the simple example above and more complex cases that I've tested only...

> Maybe we could add a similar mechanism to ChainRulesCore (an `rrule_keepthunks` or so) to provide a soft transition to (hopefully) more and more rules that support thunks in the...

> How much of a problem is it if linear operators on a Thunk unthunk them? I guess most of them will have to? > What if we made @adjoint...

> @oschulz Why do we need methods for Zero()? I thought we needed methods for Thunks? Ah, sorry, yes - in fact, more basic functions need to support (and in...

> dislike adding features to ZygoteRules when we are trying to stop using it We wouldn't really add a feature to ZygoteRules though, right? We'd just make `@adjoint` unthunk in...

> >Maybe we could offer a function unthunking in ChainRulesCore so that rrules can return y, unthunking(back) for rrules that need to unthunk. > I think better to leave that...

> I am, for the same reasons, happy for now to just leave it for the rule authors. It is still a very short function. You're right - `unthunked()` may...

> but why is it that we need a separate macro to define thunk aware adjoints? Generally, I see this more as an implementation detail which shouldn't leak to the...