Make @non_differentiable not use ::Tuple

[MasonProtter]

Hoping to fix JuliaDiff/ChainRules.jl#769

[oxinabox]

Why does duplicating prevent ambiguities?

[MasonProtter]

so first I tried without the duplication, and just putting in a ::Tuple for @scalar_rule but that was actually worse than than before, so I tried the duplication but that was also bad. I'm going to try now to remove the ::Tuple from @non_differentiable

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (77748b3) 93.79% compared to head (52c8bc6) 93.79%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #653   +/-   ##
=======================================
  Coverage   93.79%   93.79%           
=======================================
  Files          14       14           
  Lines         886      886           
=======================================
  Hits          831      831           
  Misses         55       55           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[oxinabox]

We needed that for #651

[MasonProtter]

Ah I see, I guess that's what created this ambiguity problem in the first place. :(

[MasonProtter]

I would have naively thought though that it'd be better to have @non_differentiable be lower-precendence than other methods, so that it's easier to override. If you have a differentiable method, you wouldn't want that to tie with the non-differentiable method

[oxinabox]

I would have naively thought though that it'd be better to have @non_differentiable be lower-precendence than other methods, so that it's easier to override.

Yes, unfortunately julia does not have a way of saying "This method always loses ambiguity fights"
(I guess because then you would just have a later ambiguity fight if two methods had it)

[MasonProtter]

Having the ::Tuple restriction on @non_differentiable makes it more specific though. Are we sure that #651 was the right way to solve those ambiguities?

Or maybe we should just solve this by dealing with the rules for zero and one differently.

We currently do

@non_differentiable one(::Any)
@non_differentiable zero(::Any)

and

@scalar_rule one(x) ZeroTangent()
@scalar_rule zero(x) ZeroTangent()

Maybe we should just be manually writing the rules for these functions to instead do

if x <: Number
    ZeroTangent()
else
    NoTangent()
end

?

[oxinabox]

Are we sure that #651 was the right way to solve those ambiguities?

We are not.

I think maybe we should just delete:

@non_differentiable one(::Any)
@non_differentiable zero(::Any)

[oxinabox]

closing in favor of JuliaDiff/ChainRules.jl#770