You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On #807, one option that i did not see considered is the posibility of defining an available (if experimental) tagging API, with ForwardDiff.Tag as it's only available implementation in ForwardDiff, via an AbstractTag{F,V} supertype.
For example, one package implementing StaticTag{F,V} <: AbstractTag{F,V} (in particular, #807 (comment) without the fallback) could define their own static comparison mechanism, without compromising the current runtime capabilities that ForwardDiff already gives with their own Tag implementation, and erroring when there there is any ambiguity (closures of duals) instead of recurring to checking a global value.
Another example was an attempt done in #748. While the discussion on that PR was long and the PR was finally reverted, that PR inadvertly required following a currently private tagging API:
checktag
≺
replacing most hardcoded Tag constructors by an overloadable maketag method
While i agree that the current Tag mechanism is adequate for most automatic differentiation workloads, new use cases, like completely compiled evaluations, merit thinking about the current invariants baked in the package, in my opinion. In this context, the implementation of a tagging API just shifts the burden from the ForwardDiff developer to the developer of the tagging mechanism.
Activity