Well, it's not clear to me that a PhotoCalib is really a value type rather than a utility class. In the former case, we should support hashability, just so that future developers don't have to waste time going "oh, it looks like I wasn't supposed to do that"; in the latter, it doesn't make sense. It sounds like John Parejko leans toward a PhotoCalib being a value.

The main problem is a purely technical one: the way C++ handles hashing works very poorly with polymorphism, and therefore BoundedField, so supporting hashing is a lot more work than supporting equality. So based on the expense I agree with John Swinbank that we shouldn't make it a priority.

If the use cases we've had so far are not just in unit tests, I would be interested to hear about them.  To me, PhotoCalib fits into a very common category of class (for us) in which it's super useful to have equality comparison for the purposes of writing tests, but it's never needed in any kind of regular/pipeline context.  I think it's often tempting but only sometimes productive to satisfy the need for test comparisons by adding equality to the class itself, essentially because I think the test comparisons can often afford to make simplifying assumptions that cannot be made more generally.

Re: equality, I think my uses were "is this persisted object the same as that other one?" From two runs of jointcal for example.

This is now officially an "old" ticket. It seems like the debate was not resolved back in 2019. Do we still want to do this ticket?

I'm just going to call it Won't Fix since I don't think we have a strong case for a hash function, though John Parejko has convinced me that the equality operator definitely should stay.