Implementing Equality and Hash

[philocalyst]

Would you consider a branch or feature, or perhaps just the default being using OrderedFloat instead of the regular f64, so the Node type could implement Eq and Hash? I've found it to be useful in my own environment, I have a working fork.

[ISibboI]

Thanks for the proposal, I think making Node implement Eq and Hash would be great.

I would not want to make OrderedFloat or something like this the default, but having a feature flag that contains the necessary implementations to use OrderedFloat (as well as conditionally depends on the corresponding crate) would be great.

For implementing Eq and Hash, I just checked that simply adding the derives does not work. Instead, a manual implementation would be appreciated, that implements Eq and Hash if the numeric types both implement them as well.

[philocalyst]

Okay, for the record the implementation would look similar to the Serde support, OrderedFloat removes the need to have manual implementations, its just enables the default derive macros. I'll PR a change that implements that in the coming week.

[ISibboI]

The default derive macros fail if types that are not eq and hash are being used. Hence the manual implementation is necessary to enable Node to implement Hash and Eq also for other numeric types that are Hash and Eq. The implementation would look something like:

impl<NumericTypes: EvalexprNumericTypes> Eq for Value<NumericTypes> where
    NumericTypes::Int: Eq,
    NumericTypes::Float: Eq {
    // ...
}

If I understand it correctly, these need to be done for Value, Operator, Node, and maybe some other types.

[philocalyst]

So you're saying that the manual implementation would be for when OrderedFloat is not used? Because when ordered float is in play, the derive macros work, because the only roadblock is the float's inclusion (which it would replace)