为什么Rust禁止实现现有类型？

Question

How is this...

impl String {
    fn foo(&self) {
        //...
    }
}

...any different to this?

fn foo(s: &String) {
    //...
}

Then again, it is possible to extend the type implementation if you define a trait in your crate. Why?

Answer 1

There are several different arguments as indicated by the following source as to why one is unable to implement existing types that are outside of one's crate.

• Local impl can be broken by future implementations. For example, consider "you've locally defined Add on Vec<T> as a concat operator, ... , and then ... after years of debate ... some mathy operation [is] to be performed instead. If you delete your impl and upgrade, your code will be ... broken ² ."

• The readability of the code will also be affected by this change, that is, it could make the "value of that reading far more transient ³ ."

• There is also a security concern. Consider the following scenario that would be technically possible if this were allowed, that is, "an attacker [could] find a change in an impl in [some] library, a call site in an application they wish to backdoor, and send a "refactoring" pull request that "accidentally" replaces the new impl with the old impl so as to create a vulnerability, but their pull can reference the old code from the library. And they can embed the hostile impl into a macro in yet another create ⁴ ."

• Assuming the case that the local impl would be the preferred implementation if local impls were allowed. This would "would violate the coherence property [that is currently being maintained] ⁵ ." This point can be further clarified through what is called the 'HashTable' problem ⁵ .

   mod foo { impl Hash for i32 { ... } fn f(mut table: HashMap<i32, &'static str>) { table.insert(0, "hello"); ::bar::f(&table); } } mod bar { impl Hash for i32 { ... } fn f(table: &HashMap<i32, &'static str>) { assert_eq!(table.get(0), Some("hello")); } }