Rust中整数内置方法的类型推导为何与trait实现存在差异？

示例代码如下：

trait Fun {
    fn fun(self, other: Self);
}

impl Fun for i64 {
    fn fun(self, other: Self){
        println!("i64");
    }
}

impl Fun for i32 {
    fn fun(self, other: Self){
        println!("i32");
    }
}

impl Fun for u32 {
    fn fun(self, other: Self) {
        println!("u32");
    }
}

fn main() {
    0.saturating_add(1); // 编译失败
    0i32.saturating_add(1); // 编译通过
    0.saturating_add(1i32); // 编译失败

    0.fun(1); // 编译通过，推导为i32
    0.fun(1u32); // 编译通过，推导为u32
    0u32.fun(1); // 编译通过，推导为u32
}

两类方法推导逻辑的核心区别 #

两类方法表现不一致，本质是Rust对固有方法（inherent method，即saturating_add这类各整数类型直接实现的内置方法）和trait方法的解析流程完全不同：

• 固有方法的推导规则 #

  固有方法是直接绑定在具体类型上的方法，不属于任何trait。方法解析的第一优先级是确定接收者（即.前的表达式）的具体类型，只有拿到接收者的确定类型，编译器才能去该类型的固有方法列表里查找匹配的方法，这个过程不会让参数的类型信息反向流向接收者。
  对应示例中saturating_add的三个调用场景：

  1. 0.saturating_add(1)：接收者0无后缀、无其他类型约束，参数1也无类型标注，编译器无法确定接收者到底是哪种整数类型，找不到对应的saturating_add实现，直接报错。
  2. 0i32.saturating_add(1)：接收者明确标注为i32，编译器直接匹配i32的saturating_add方法，参数1会被自动推导为i32，编译通过。
  3. 0.saturating_add(1i32)：哪怕参数明确标注为i32，固有方法解析阶段不会用参数类型反推接收者类型，编译器依旧无法确定0的具体类型，编译失败。

• trait方法的推导规则 #

  trait方法的解析是双向类型统一过程：编译器会同时收集接收者、所有方法参数、返回值的类型约束，把所有约束汇总后再匹配当前作用域内的对应impl，类型信息可以在接收者和参数之间双向流动。
  另外Rust对无约束的整数字面量有默认回退规则：如果整数字面量经过所有约束推导后依然没有确定类型，会默认fallback为i32。
  对应示例中fun的三个调用场景：

  1. 0.fun(1)：接收者和参数都没有明确类型标注，也没有其他额外约束，触发整数默认回退规则，两个字面量都被推导为i32，匹配i32的Fun实现，编译通过。
  2. 0.fun(1u32)：参数明确标注为u32，而Fun的方法签名要求other: Self，即参数类型必须和实现trait的Self类型一致，这个约束会反向传递给接收者0，推导0为u32，匹配u32的Fun实现，编译通过。
  3. 0u32.fun(1)：接收者明确标注为u32，参数1会顺着Self的约束被推导为u32，匹配u32的Fun实现，编译通过。

补充说明：固有方法不做反向推导是为了避免歧义——多个不同类型可以拥有同名、同参数签名的固有方法，如果允许用参数类型反推接收者，会出现大量无法确定唯一实现的场景。trait因为有统一的trait约束作为匹配依据，双向推导不会产生这类歧义问题。

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