Rust标准库中Add trait为何使用Output关联类型？

Rust标准库中的Add trait定义如下：

trait Add<Rhs = Self> {
    type Output;

    fn add(self: Self, rhs: Rhs) -> Self::Output;
}

我觉得这个设计存在冗余，比如在Complex<i32>的实现中，Output就是Self本身，于是自己写了一个省略Output的MyAdd trait：

use num::complex::Complex;

trait MyAdd<Rhs = Self> {
    fn myAdd(self: Self, rhs: Rhs) -> Self;
}

impl MyAdd for Complex<i32> {
    fn myAdd(self: Self, rhs: Self) -> Self {
        Complex {
            re: self.re + rhs.re,
            im: self.im + rhs.im,
        }
    }
}

fn main() {
    println!("Hello world!");
    
    let c1: Complex<i32> = Complex::new(1, 0);
    let c2: Complex<i32> = Complex::new(0, -1);
    
    let c3: Complex<i32> = c1.myAdd(c2);
    
    println!("{:?}", c3);
}

想知道：Add trait为何要引入Output关联类型？这样设计的优势是什么？

核心原因：支持类型不封闭的加法运算 #

你的MyAdd只覆盖了「两个同类型相加、结果还是同类型」的场景，但实际编程中加法的结果类型完全可能和操作数类型不同，Output就是为了处理这类场景而设计的，具体来说有这些作用：

1. 跨原生类型的加法 #

比如i32和f64相加，Rust的设计是返回f64，如果没有Output，就没办法在trait中定义这种返回类型的差异：

impl Add<f64> for i32 {
    type Output = f64;

    fn add(self, rhs: f64) -> f64 {
        self as f64 + rhs
    }
}

如果用你的MyAdd，这里的返回类型必须是i32，显然不符合实际需求。

2. 自定义类型与原生类型的混合运算 #

假设你有一个自定义的Temperature类型，和f32相加后返回新的Temperature，或者反过来，f32和Temperature相加返回f32，Output能灵活定义结果类型：

struct Temperature(f32);

impl Add<f32> for Temperature {
    type Output = Temperature;

    fn add(self, rhs: f32) -> Temperature {
        Temperature(self.0 + rhs)
    }
}

impl Add<Temperature> for f32 {
    type Output = f32;

    fn add(self, rhs: Temperature) -> f32 {
        self + rhs.0
    }
}

3. 泛型场景下的类型推导与约束 #

在泛型代码中，Output可以让我们明确约束加法的结果类型，或者基于结果类型做进一步操作。比如写一个通用的求和函数，要求加法结果能继续参与运算：

fn sum<T: Add<Output = T>>(nums: Vec<T>) -> T {
    nums.into_iter().fold(T::default(), |a, b| a + b)
}

如果没有Output，这种泛型约束会变得非常受限，只能处理同类型相加返回同类型的场景。

4. 运算符重载的统一性 #

Rust的运算符重载依赖这些trait，Add、Sub、Mul等都遵循相同的设计模式，统一使用Output关联类型，让开发者能一致地理解和实现运算符逻辑，同时也让编译器能统一处理类型推导。

内容的提问来源于stack exchange，提问作者user2138149