How do I implement a trait I don't own for a type I don't own?

Question

I wanted to implement the Shl trait for Vec, the code is below. This would make things like vec << 4 possible, which would be nice sugar for vec.push(4).

use std::ops::Shl;

impl<T> Shl<T> for Vec<T> {
    type Output = Vec<T>;

    fn shl(&self, elem: &T) -> Vec<T> {
        self.push(*elem);
        *self
    }
}

fn main() {
    let v = vec![1, 2, 3];
    v << 4;
}

The compilation fails with the following error:

cannot provide an extension implementation where both trait and type are not defined in this crate [E0117]

or

type parameter T must be used as the type parameter for some local type (e.g. MyStruct<T>); only traits defined in the current crate can be implemented for a type parameter [E0210]

As I understand it, I'd have to patch the stdlib, more specifically the collections::vec crate. Is there another way to change this code to compile successfully?

10

This is impossible by design. – A.B. Aug 20 '14 at 20:28

score 100 · Accepted Answer · edited Jan 21 '18 at 17:56

100

While you can't do that exactly, the usual workaround is to just wrap the type you want in your own type and implement the trait on that.

use somecrate::FooType;
use somecrate::BarTrait;

struct MyType(FooType);

impl BarTrait for MyType {
    fn bar(&self) {
        // use `self.0` here
    }
}

edited Jan 21 '18 at 17:56

Shepmaster

388,571
95
1,107
1,366

answered Aug 20 '14 at 22:10

Luqman

1,348
1
9
6

23

Appendix: implement the Deref trait to avoid typing `.0.foo` everytime – Dev Aggarwal Sep 06 '20 at 16:40
2

Is this still a valid approach in 2020? – max Sep 25 '20 at 01:16
4

@max yes. This "limitation" is one of core thing that make rust so good language. So this is still valid in 2020 and will be valid probably forever in Rust version 1 . – S.R Nov 10 '20 at 15:49
Is this approach with a struct at all better than using a named field? – Christian Bongiorno May 26 '22 at 17:29
3

@ChristianBongiorno I'd say that the tuple struct is a bit cleaner, and more obvious that it intends to be a newtype, than it would be if it had named fields. – Jeremy Meadows Jul 14 '22 at 12:30

malbarbo · Answer 2 · 2016-06-24T16:41:34.057

This would make things like vec << 4 possible, which would be nice sugar for vec.push(4).

Although it can be done, it is generally a bad idea to implement an operator with a unexpected semantic.

Here is an example of how this can be done:

use std::ops::Shl;

struct BadVec<T>(Vec<T>);

impl<T> Shl<T> for BadVec<T> {
    type Output = BadVec<T>;

    fn shl(mut self, elem: T) -> Self::Output {
        self.0.push(elem);
        self
    }
}

fn main() {
    let mut v = BadVec(vec![1, 2, 3]);
    v = v << 4;
    assert_eq!(vec![1, 2, 3, 4], v.0)
}

If you implement Deref (DerefMut):

use std::ops::{Deref, DerefMut};

impl<T> Deref for BadVec<T> {
    type Target = Vec<T>;

    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

impl<T> DerefMut for BadVec<T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.0
    }
}

you can call Vec methods:

fn main() {
    let mut v = BadVec(vec![1, 2, 3]);
    v = v << 4;
    v.truncate(2);
    assert_eq!(2, v.len());
}

Take a look at the newtype_derive crate, it can generate some boilerplate code for you.

There's an informative note in the official docs: "Implementing `Deref` for smart pointers makes accessing the data behind them convenient, which is why they implement `Deref`. On the other hand, the rules regarding `Deref` and `DerefMut` were designed specifically to accommodate smart pointers. Because of this, `Deref` should only be implemented for smart pointers to avoid confusion." https://doc.rust-lang.org/stable/std/ops/trait.Deref.html — Tim Abell, Jun 26 '22 at 17:25

snnsnn · Answer 3 · 2022-11-09T08:53:02.897

That is intentionally forbidden and referred to as the orphan rule. It is for guaranteeing trait coherence. According to the orphan rule, you cannot provide implementations of a trait for a struct unless you are either the crate that defines the struct, or the crate that defines the trait. If you could achieve what you are asking, we would have conflicting implementations circling around.

There are some workarounds though, the most common one being the newtype pattern. In the newtype pattern, we wrap the external type in a local struct and through this wrapper we implement the desired methods.

// External struct
use foo::Foo;

// Create a new type.
pub struct Bar(Foo);

// Provide your own implementations
impl Bar {
    pub fn new() -> Self {
        //..
    }
}

For more information check out these references:

How do I implement a trait I don't own for a type I don't own?

3 Answers3

Linked

Related