Here's a list of features mentioned in the manifesto but out of scope for this proposal:
- Forward-mode differentiation and general differentiable functions (
@differentiable), i.e. functions which, when differentiated, can produce both a differential (computes directional derivatives) and a pullback (computes gradients). Same for@differentiable(linear). As a result, forward-mode differential operators and the linear transpose operator such asdifferential(at:in:)andtranspose(of:)have been taken out as well. A full list of proposed differential operators can be found here.- This proposal is motivated by the dominant use cases of differentiation and therefore restricted to reverse-mode differentiation for the time being — it uses a more specific
@differentiable(reverse)attribute, while reserving@differentiablefor a potential future proposal.
- This proposal is motivated by the dominant use cases of differentiation and therefore restricted to reverse-mode differentiation for the time being — it uses a more specific
- Implied generic constraints on differentiable closures.
- Differentiating with respect to captured variables in a closure.
- Default derivatives for differentiable protocol requirements in protocol extensions.
The manifesto also mentioned a number of general features that aren't directly related to differentiable programming. These are out of scope for this proposal as well:
- Anonymous functions, aka.
func _in the manifesto. This would be a general-purpose feature which I think can be pitched separately to support use cases beyond differentiation (e.g. dynamic method replacement). - Compiler-synthesized conformances for
AdditiveArithmetic. @memberwiseattribute for triggering derived conformances. Explicit derivation is a general feature that I think deserves its own proposal so that other derivable protocols can adopt it.