segmentation fault: moved value not detected due to trait usage

[dhardy]

With a little bit of hacking, I found a memory safety violation:

// This causes a seg-fault.

struct S<T> { val : T }
trait Gettable<T>{
    fn get(&self) -> T;
}
impl<T : Copy> Gettable<T> for S<T> {
    // Note: ~str does not satisfy Copy yet this compiles
    fn get(&self) -> T { self.val }
}

fn main() {
    let t : Box<S<~str>> = box S { val: "one".to_owned() };
    let a = t as Box<Gettable<~str>>;
    let b = a.get();    // causes a move
    //Note: without use of a trait, doing this results in:
    //error: instantiating a type parameter with an incompatible type `~str`, which does not fulfill `Pod`

    println!( "a: {}", a.get() );       // another move, crash ensues
    println!( "b: {}", b );
}

Note: what's the best way to "get" a value via a trait? Copy and restrict to POD types? Reference, even if most of the values accessed are just ints? Or use clone − and risk issues on complex types?

[edwardw]

A workaround is to define the built-in bound on the trait instead of the implementation:

trait Gettable<T:Copy>{
    fn get(&self) -> T;
}

Then the "not fulfill Pod" error is caught as expected. This could be a backward compatibility hazard. Nominate?

[dhardy]

So a fix might be for the compiler to notice that if an impl is defined on a more restricted type than the trait then either additional impl(s) are needed or the implementation is invalid?

[nikomatsakis]

cc me

[pnkfelix]

assigning P-high, Milestone 1.

[nikomatsakis]

this looks related to #5527 etc

[pcwalton]

Nominating for closing as a dupe of #2687. If this is not a dupe, then it must be P-backcompat-lang.

[nikomatsakis]

I am not sure this is a dup of #2687 -- that is specific to bounds on methods.

[brson]

1.0, backcompat-lang.