You're right that the impls can be static, in which case interfaces
don't enter into it. Also, method names can overlap in Rust (unlike in
Haskell) without causing conflicts. So I guess this is not a direct
issue. And yes, I do intend to implement support for super-interfaces,
they seem to be
Currently it is simply '+'.
The thing that prompted this is issue #1520 -- operator overloading.
Delegating + on non-builtin-numeric types to a `num` interface that
implements methods add/sub/mult/div/rem/neg methods seems elegant, and
similar to Haskell's approach. Vector-concatenation + messes
On 1/25/12 11:46 AM, Marijn Haverbeke wrote:
Currently it is simply '+'.
The thing that prompted this is issue #1520 -- operator overloading.
Delegating + on non-builtin-numeric types to a `num` interface that
implements methods add/sub/mult/div/rem/neg methods seems elegant, and
similar to
What about an add interface?
That works, but doesn't provide the conceptual simplicity of a number
interface, and if you want to write a generic over any numeric type,
it could end up taking a T: add, mult, sub, div type parameter.
___
Rust-dev mailing
There are cases in math or physics when the granularity is needed. For example,
when implementing vectors (in the math or physics sense), it doesn't make sense
to define a division operator, and what you mean by multiplication depends on
if you mean dot product, cross product, or whatever. It'd
On 1/25/12 12:18 PM, Marijn Haverbeke wrote:
That works, but doesn't provide the conceptual simplicity of a number
interface, and if you want to write a generic over any numeric type,
it could end up taking aT: add, mult, sub, div type parameter.
It seems to me that if impls did not have to
