I'm really excited to see this proposal making progress -- congratulations. I also am happy to see this cut down a bit to make the first step more reasonable. You've all obviously put a lot of thought and consideration into this, but here are a few thoughts and questions:
I don't see the @memberwise Differentiable
concept explored much, why a new attribute and what does it mean? The existing codable and equatable autosynthesized conformances are also memberwise and don't use an attribute, why is something new required here? The only mention implies it has something to do with the TangentVector
synthesis, but I don't understand why it is required - why not synthesize it when absent like codable and equatable do for their requirements?
Is +=
differentiable? if so, the first Perceptron example can use it in the loss calculation. If not, why not?
Random annoyance but the term "differential operators" is really weird in Swift since these are methods, not operators in the Swift sense. I'd love to find another word to describe these things.
Should Differentiable
require AdditiveArithmetic
? This would make generics code simpler (e.g. the definition of TangentVector
in several places, Point
and multiple examples in this section) and it isn't clear to me if anything of merit is Differentiable without being additive. It might simplify the system overall, as well as its description in the document.
... oh, this breaks Array I guess? Yuck. Maybe there should make the base protocol be "DifferentiableButNotNecessarilyAdditive" and make "Differerentiable" be that plus Additive, since the combination seems like vastly the most common case. Maybe this isn't the right way to go, but it seems like we need a single name for the combination of these two protocols.
I'm used to "move(along:)
" but perhaps offset(by:)
is worth considering. I agree with others in the thread that +=
would be the wrong thing here given the asymmetric nature of the operation.
Why isn't zeroTangentVectorInitializer
a func requirement? The behavior definition is a bit weird so it must be intentional. Please capture the rationale in the proposal. I'm curious to know what the efficiency implications of this are vs a standard func requirement. In the absence of inlining, is the closure allocated each time the getter is called and has its lifetime managed by ARC?
The "not required but warned about" behavior of the @noDerivative
attribute makes sense to me. The name still isn't great - is there any way to turn this into a word with a positive sense, e.g. @stationary
, @discrete
or something like that? I believe that our prior art for negative things is the "non" prefix, and @nondifferentiated
is weird.
I think the second example in this section has a minor bug, the input
parameter isn't declared in Layer but is referred by the @differentiable
attribute.
I like the integration of the @transpose
attribute to make @differentiable(linear)
functions. I think that the (already extensive) background above could mention linear functions and why they are an important special case to model in the function type system. Dropping the distinction between linear types and other differentiable functions would simplify things, so there should be clear rationale for their inclusion.
I think that func _
should be a separate proposal, I'd recommend using underscore prefixed names (like _foo
) in this proposal to avoid distraction.
Trivial typo in this section: you're missing a )
in the "Complex differentiation is representable" paragraph.
The @noDerivative
attribute on function parameters is a bit weird to me, it is more like a @notWRT
attribute or something. I'm not sure what the right name is here though.
What evolution limitations will be caused by taking this proposal, e.g. without higher order differentiation? If the differential operators will have to change, does that cause ABI or other problems? Will these be defined as "always inline into client" in the meantime or something to mitigate any of these problems?
I'd recommend moving the "future directions" section after the "effect on ABI/API" sections since they apply to the base proposal, not the future directions.
Overall, I'm very excited to see the years of work on this coming together!
-Chris