rustc doesn't reject incompatible trait and impl methods w.r.t argument bounds

[edwardw]

The following is extracted from libnative / libgreen implementation of std::rt::Runtime:

pub trait Runtime {
    fn spawn_sibling(&self, f: proc():Send);
}

pub struct Foo;
impl Runtime for Foo {
    fn spawn_sibling(&self, _f: proc()) {}
}

fn main() {}

The implementation misses the Send bound of one of its argument so it should not compile, but currently it does.

[alexcrichton]

Oh dear, that's bad. Nominating.

[edwardw]

I found this when fiddling with variance in order to fix #12223 and #13497. They seem to be all related.

[brson]

1.0 backcompat lang.

[edwardw]

Consider the example given above and the one below:

pub trait T1 {}
pub struct S;
impl T1 for S {}

pub trait Runtime {
    fn spawn_sibling(&self) -> Box<T1:Send>;
}

pub struct Foo;
impl Runtime for Foo {
    fn spawn_sibling(&self) -> Box<T1> {
        box S as Box<T1>
    }
}

fn main() {}

Intuitively, they are both wrong. But currently rustc accepts the former and rejects the latter. The reasoning here seems to be: in the first example, f is at a contra-variant position, in order to be compatible, the argument being used in the implementation (proc()) must be contra-variant to the one being used in the trait definition (proc():Send), i.e. proc():Send <: proc(), which happens to be true. In the second example, the type in question is at a co-variant position, but Box<T1> <: Box<T:Send> is not true, thus an error.

So by the usual variance rule, the current behavior is actually correct! Very counter-intuitive. I'm not sure why built-in bounds here makes an exception to the variance rule.

[nikomatsakis]

cc me