Changes for 0.5

[willtebbutt]

There are a couple of changes that I want to make that are breaking. In particular,

1. use Config directly in build_rrule, prepare_gradient_cache, and prepare_pullback_cache, etc, rather than passing in kwargs, and
2. redesign prepare_pullback_cache and value_and_pullback!! so that they're possible to use without requiring a call to zero_tangent.

This will bring immediately advantages to DI's interface with Mooncake. For example, if we add fields to Config (in a non-breaking way), DI won't need to change to support them. It should also reduce the amount of kwargs... expressions floating around in the Mooncake codebase, which can only be a good thing. Moreover, the change to prepare_pullback_cache and value_and_pullback!! ought to ensure that DI only needs to use these two functions + Mooncake.Config (i.e. what we're calling the public interface), and not anything else.

Technically non-breaking changes I plan include:

1. removing "convenience" methods of build_rrule. I'm anticipating that all users should generally be using prepare_{gradient,pullback}_cache, so the convenience methods are redundant. If people need to use this (internal) function, they will obviously still be able to.
2. Separating uses of CoDual into distinct types #275 , which is very breaking.

I expect to add to this list before actually making the release.

If anyone happens to know of any unsatisfactory bits of Mooncake which, whether technically breaking or just "probably disruptive to someone", ought to go into 0.5, please feel free to mention them here!

[aj-fleming]

Far beyond the scope of this issue, but what would happen for Mooncake to need to support the differentiation of vector-valued functions?

[willtebbutt]

If by support differentiating vector-valued functions you mean compute Jacobian-like things, then I would suggest taking a look at DifferentiationInterface -- It's default Jacobian computation functionality already works for Mooncake :)