Make `Optional` conditionally conform to `Differentiable` when the `Wrapped` type does.
`Optional.TangentVector` is a wrapper around `Wrapped.TangentVector?`.
Also, fix `Array.TangentVector.zeroTangentVectorInitializer`.
Resolves TF-1301.
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
`Differentiable` conformance derivation now supports
`Differentiable.zeroTangentVectorInitializer`.
There are two potential cases:
1. Memberwise derivation: done when `TangentVector` can be initialized memberwise.
2. `{ TangentVector.zero }` derivation: done as a fallback.
`zeroTangentVectorInitializer` is a closure that produces a zero tangent vector,
capturing minimal necessary information from `self`.
It is an instance property, unlike the static property `AdditiveArithmetic.zero`,
and should be used by the differentiation transform for correctness.
Remove `Differentiable.zeroTangentVectorInitializer` dummy default implementation.
Update stdlib `Differentiable` conformances and tests.
Clean up DerivedConformanceDifferentiable.cpp cruft.
Resolves TF-1007.
Progress towards TF-1008: differentiation correctness for projection operations.
In Podcast Player example of Intelligent Systems, struct `Observation` has var `podcastState`, while it has been referenced as `state` in the following cell. Changed it to `podcastState`.
Currently, when a conforming type implements a `@differentiable` protocol requirement, the corresponding conforming implemnetation is required to have at least a `@differentiable` that covers all differentiability parameters in the protocol requirement. However, this is not a great design for usability because developers almost always start with missing `@differentiable` and getting an compilation error. This also makes ML models built with libraries that use differentiable programming more verbose than those built with other ML frameworks.
We agreed during this Friday's design review to allow `@differentiable` to be implicitly inherited from protocols when the conforming implementation is non-public.
* `Builtin.autodiffApply*` has been renamed to `Builtin.applyDerivative*`.
* The reason I'm not adding `_jvp` is because there will no longer be `_vjp`, which will make this suffix entirely unnecessary.
* The transpose application builtin is named `Builtin.applyTranspose*`.
In the code review for #28321, the main developers of AutoDiff agreed to rename `@differentiating` and `@transposing` to `@derivative(of:)` and `@transpose(of:)`, respectively. This PR updates the manifesto to reflect this change.
