That's matrix transposition, not inversion.
Whoops, shows I don't know the names of this stuff off the top of my head
The general point stands, though: if it's not useful for input parametricity, it doesn't really need to be a trait anyway.
Just to bring it up - there exists one inversion operator -
std::ops::Not which uses the
Boolean negation is quite familiar as an inversion, and bitwise inversion also uses this operator. That's about it. That said, the trait definition doesn't quite say it's an inversion, it says The unary logical negation operator
std::ops traits don't assign semantic meaning to operations - even if I think having that, is better - you just use the appropriate trait for the operator you want to implement, if you do. (See string concatenation using
+.. which brings up what I'd want to add, a concat operator.)
There's also std::ops::Neg which is an additive inverse.
Neg has syntax,
-x, similarly for the only other math-related prefix operator
I agree with this point, but I don’t necessarily think it applies here. Inverting is a meaningful operation in any situation where multiplication is defined and a multiplicative identity exists. On the other hand though, there aren’t many types in the standard library where such an operation might be useful: only the floating-point types, and potentially
Wrapping<_>. For integers, the only invertible elements are 1 and −1, and other types have no multiplication defined at all.
So I agree with everyone saying that for the time being, such a trait should probably live in an external crate. But even if it were added to the standard library,
std::ops would be a bad place for it, because traits in that module are tied to operators, and there is no inversion operator in Rust.
I don't really have much to add to Felix's response, I've proved some stuff about inverses before inverse.lean in case anyone wants to look at it stated formally... In that case we're dealing with a relation between a pair of unary functions, I think there is much more room for optimizations in the compiler that way, over the trait based mechanism here.
Anyhow, there is another std type which could implement
Rust has made a choice to provide a minimal set of math-related traits and methods in core/std, with the goals of allowing operator overloading and exposing intrinsics and native library functions for specific types, rather than providing general mathematical abstractions, delegating those to other crates (currently there is num_traits and alga, possibly others).
Hence, this would not be an appropriate change.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.