Should we remove fallback rule?

[mzgubic]

ChainRulesCore provides fallback rrules and frules which return nothing. I believe the original use case for this was to make help Cassette with type inference, but Cassette is not being used anymore.

Removing the fallbacks would result in a MethodError being thrown, which is arguably more informative than the current convention of nothing being returned.

Removing the fallback method would require modifying how Zygote decides whether an rrule exists or it should be generated
https://github.com/FluxML/Zygote.jl/blob/7c66eff0a9200b1095f1c94ac6faec9f16b740fe/src/compiler/chainrules.jl#L12-L20

There is ongoing related work to take nothing seriously

[mzgubic]

We can avoid things like https://github.com/JuliaDiff/ChainRulesTestUtils.jl/blob/203fce008b55540b7e86ba6da5d345939d176a46/src/testers.jl#L112

[willtebbutt]

I buy that this seems reasonable, but I'd want know how under whatever system we had instead, it would be possible to say "ignore that generically-typed rrule for this particular collection of argument types -- just run AD".

[mzgubic]

I guess we could still do that with a nothing convention?

[willtebbutt]

Hmm I suppose. My instinct is that I'd rather avoid increasing the number of ways of saying that a rule doesn't exist though.

[mzgubic]

Hmm I suppose. My instinct is that I'd rather avoid increasing the number of ways of saying that a rule doesn't exist though.

One way is to return nothing. What is the other way of saying a rule does not exist? Just the rule not existing?

Edit: A: if we remove the fallback method, then both MethodError and return type nothing mean that the rule does not exist.

[Keno]

I would probably advise against this. Checking for the existance or non-existance of a MethodError is signficantly more expensive than checking for nothing.

[oxinabox]

Ok, I am sold, staying as is