I just can’t shake concerns that it sits at the wrong level of generality.
That’s not a concern about complexity; the proposal is less complex than most type system proposals. It’s also not a concern about utility; this would be a useful feature for many. It’s a concern about generality appropriate to a general-purpose language.
The “function builders” proposal is a useful contrast to this one: motivated by and built for SwiftUI, yet clearly general enough to sit at the language level.
Let’s run with that analogy.
Imagine a Swift without closures. I could imagine, say, a proposal to add “callbacks” as a first-class language feature. Functions may be marked with @acceptsCallback. Such functions may be called with a trailing block of callback code, which is passed to the @acceptsCallback function as, say, a compiler-generated Callback that has a call method … etc.
It’s … almost closures, but it’s not. The structure and terminology keep it narrow in its potential applications. It undeniably has broad applications, yet still feels a bit too specific to be a language-level feature. It seems like it would make a nice library, but needs compiler support.
That’s where this proposal sits for me. Thank goodness we have closures instead! And the proposal itself lays out this concern:
That “system for custom code transformation” is what the proposal makes me wish for — and I wish the proposal didn’t gloss over it. Imagine a system for AST transformation that could make “differentiable” a library, and it’s easy to imagine other exciting uses as well. That seems like what we should be aiming for here in the long term.
All of this isn’t really a -1 on this proposal per se. It’s a request for more forward-looking context in the proposal’s development. If we do bake differentiable programming into the language for now, I hope it fits into some larger future vision. What might such a generic AST transformation proposal look like? Is this work on differentiable programming a step toward it? Would this proposal likely fit sensibly into such a future system, both in syntax and behavior?
There’s a danger here of baking something into the language that seemed compelling in tech’s current moment, but had too many specific design decisions baked in before the motivating trend had matured, and ended up being compatibility baggage the language must maintain long after the problem domain has moved beyond it. Think of Java Swing.