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

[nikomatsakis]

I am not sure yet that this is broken. I think it is expected behavior.

[nikomatsakis]

Specifically, impls can require less than traits require. The idea is: if I didn't know the impls type, and I only know the trait type (as in a generic fn), I will pass in a proc():Send. The impl will then be invoked. Since a proc:Send <: proc, this is ok. In other words, the impl is ok with any proc, not just a sendable one.

[nikomatsakis]

That said, I'm not sure there is much purpose to permitting this kind of subtyping, and it might make sense to tighten up the rules just so people don't get surprised. The original goal was to permit impls to act as a kind of refinement, so that in cases where we did know the static type, we could use the tighter types from the impl, rather than the more generic types from the trait, but I don't think this is how our method resolution will work anyway. And you could always declare an inherent method for places where this matters.

[flaper87]

cc @flaper87

[edwardw]

Also, the "Taming the Wildcards" paper does mention that a type parameter lower bound is contra-variant in itself. The way we use built-in bounds here, i.e. at least Send, makes it lower bound, I presume. If such an interpretation is correct, then the first example will become invalid while the second valid.

Either way, this is rather subtle and could be a surprise.

[pcwalton]

Nominating for closure as a dupe of #2687.

[brson]

Closing as expected behavior.