Description
There are a couple of changes that I want to make that are breaking. In particular,
- use
Configdirectly inbuild_rrule,prepare_gradient_cache, andprepare_pullback_cache, etc, rather than passing in kwargs, and - redesign
prepare_pullback_cacheandvalue_and_pullback!!so that they're possible to use without requiring a call tozero_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:
- removing "convenience" methods of
build_rrule. I'm anticipating that all users should generally be usingprepare_{gradient,pullback}_cache, so the convenience methods are redundant. If people need to use this (internal) function, they will obviously still be able to. - 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!