Consider splitting [Partial]Eq/Ord into separate traits/operators

[mathstuf]

While expression templates are neat, I don't think I'd trade them for the current set of operator traits due to the "trust" they allow me to currently have when reading code. Not to mention that in your example,

@DanB

solve([x + 2 == x.pow(2), x > 4, x <= 20], [x]);

would need to have that first argument have consistent types, probably Box<dyn Expression> which would require wrapping in Box::new(arg) as Box<dyn Expression> (though maybe type inference can elide the as part). I suppose you could have this be a huge enum, but then it would be full of Boxes due to the recursive nature of just about every operator. I feel like a macro that matches on the tokens of the operators and builds the tree that way would work better myself. You could even then have x**2 instead of x.pow(2). Or 2**x instead of the (otherwise impossible) 2.pow(x).

@DanB

// or, if && and || were overloadable, then perhaps:

See these threads:

• `ControlFlow`: The Answer to `BoolAnd`/`BoolOr`
• A different way to override || and &&
• Pre-RFC: Overload Short Curcuits

Prior discussion:

• [Pre-RFC] Boolean operators that don't return bool