Josh Stone

It can't be that generic because it conflicts with the broad `impl From for T` -- the compiler sees that it is _possible_ to have `S = Complex`, no matter...

I don't have an issue with putting security response under t-infra. It's a better fit than "launching pad" at least, and if we feel that there's a problem with this...

Are you using a generic `T` in your code? What type constraints do you have? The implementation of these traits requires `T: Clone + NumAssign`, e.g. [`AddAssign for Complex`](https://docs.rs/num-complex/latest/num_complex/struct.Complex.html#impl-AddAssign%3CT%3E-for-Complex%3CT%3E).

It's meant to be able to manifest a zero out of thin air -- e.g., `iter.fold(T::zero(), |acc, x| ...)`. For your enum, I suppose you'll have to pick a "default"...

> (I could implement Add, Ord etc...) If your `Add` runs with different operands, say `UInt8(1) + Float64(2.0)`, does it work? If you can mix variants, then it doesn't really...

FWIW, here's a real use of getting zero without any "reference" value: https://docs.rs/ndarray/latest/ndarray/struct.ArrayBase.html#method.zeros

You could also have a special `AnyNumber::Zero` variant, if you don't want to mix variants otherwise -- depending on how much you're willing to deal with `Zero` everywhere. (And maybe...

Note that the current `OccupiedEntry` holds a `&mut HashTable`, which means we **cannot** have multiple entries in existence at the same time -- the `Iterator` API is _too_ flexible for...

How about tests that demonstrate the improved accuracy?

Does the accuracy show itself by comparing the result squared to the original value? You may be able to use simple inputs without having to hard-code expected results. Hopefully that...