Michael Abbott

Sorry, there might be bugs. It's easy to introduce them when you slurp/splat all arguments, and don't think about the empty case. Indexing with a trailing `1` does seem to...

That's not good! Thanks for the careful investigation. It looks like this is the key difference -- the lookup from a Vector is similar, but the lookup from a range...

It could do, I'm not opposed but haven't run into a use for this myself. In https://github.com/invenia/NamedDims.jl/pull/24 this was going to be done by overloading getproperty: https://github.com/invenia/NamedDims.jl/pull/24/files#diff-11fb1118a11e25a31717086efe376fa8R101-R113 But it would...

BTW, if you disable that check with `ChainRulesCore._backing_error(P,G,E) = nothing`, then it fails by generating a Tuple and a Tangent for the same gradient. This case was not addressed in...

Thanks, that does look wrong. Looks like it has other bugs, too, when I try to test it more deeply: ``` julia> AxisKeys.findindex(Near(0.1), 3:0.1:4) ERROR: BoundsError: attempt to access 11-element...

This is also fixed in Base, where 1.6 had ``` julia> rand(3) .= ones(1,3)' ERROR: DimensionMismatch("cannot broadcast array to have fewer dimensions") ``` now 1.7 has this: ``` julia> rand(3)...

Here's the behaviour, in the order of this table, with the `===` change (which only alters 2 of them): ``` julia> using StaticArrays, ChainRulesCore julia> ProjectTo(SA[1,2])(SA[3,4]) isa SVector true julia>...

Yes, I think it's not quite `@thunk(copy(dy))` since you want to be able to read the array freely, only when writing must you be careful. But it's similar in that...

Could be. Unlike NamedDims there's some cost here to checking the key-vectors each time. I'm not wholly convinced that this thing ought to exist. We could just accept a plain...

Yes. I guess the style of this package would be to un-wrap & call the projector for the underlying NamedDimsArray?