address my comments as you will, and make sure CI is passing.
then merge when happy

Hmm, actually - what should we do about Any primal type? My initial thought was that it should be a Tuple (since there are no names), but we could allow Tuple, NamedTuple, or Dict?

Hmm, actually - what should we do about Any primal type? My initial thought was that it should be a Tuple (since there are no names), but we could allow Tuple, NamedTuple, or Dict?

Yes.
Or even allowing utterly anything.
It's basically just used as a hack in Zygote, but let's not break that hack.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.90%. Comparing base (bde3166) to head (d1a9f5b).
⚠️ Report is 266 commits behind head on main.

@@            Coverage Diff             @@
##             main     #495      +/-   ##
==========================================
- Coverage   92.94%   92.90%   -0.04%     
==========================================
  Files          15       15              
  Lines         822      818       -4     
==========================================
- Hits          764      760       -4     
  Misses         58       58              

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

Diffractor (same failure on its master) and Julia nightly (test unexpectedly passes) errors look unrelated. Will merge if ChainRules tests pass

This broke Diffractor. Is this really worth it?

It could be written out using dispatch instead of if statements, maybe that would help?

No, that's not the problem. Diffractor uses tuple backing for tangents of tangents over tuples. This could probably be changed at some point, but I don't think this should have been merged without any discussion now that we have the integration test.

No, that's not the problem. Diffractor uses tuple backing for tangents of tangents over tuples.

Hmm I am not sure that it should.

But for now maybe let's revert this PR, and then we can think about it.

I don't think this should have been merged without any discussion now that we have the integration test.

Ah sorry, I think we just got used to Diffractor being broken.
But it works now that it's CI is set to use Julia nightly.

Yes, this was bad.

Just for the future: Could you please always squash merge commits like these before merging? It's just such a pain to revert otherwise. (Edit: Turns out it's not that bad if you are working off the correct branch 🤦. Squash merges are still pretty much always easier to work with though, so my point still stands.) I wonder whether we should just disallow anything except squash merge for this repo.

Hey Simeon, sorry about breaking Diffractor. The error looked unrelated and was the same one as on master at the time, so I didn't think there was anything wrong with the PR. And yes, will make sure to merge next time.

No, that's not the problem. Diffractor uses tuple backing for tangents of tangents over tuples.

Are there any reasons why a NamedTuple, e.g. Tangent{Tangent}(; backing=(1, 2, 3)) would not work? I think that would be the most consistent thing to do, unless there are good reasons to just use a Tuple?

Are there any reasons why a NamedTuple, e.g. Tangent{Tangent}(; backing=(1, 2, 3)) would not work?

I'm pretty sure that's possible, but it's not super trivial because that assumption is used in multiple places. Once I have figured that out, we should be able to relate this.

This is JuliaDiff/Diffractor.jl#67, BTW.