comparing bounds on impl method type parameters with bounds declared on trait is completely bogus

[nikomatsakis]

Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn.

UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like:

trait Foo {
    fn m<T:Eq>(...);
}

then in the impl, the m method should take one type parameter with an Eq bound. We don't really check this correctly though. As far as I can tell, we just check that m has one type parameter with one bound, but not precisely what kind of bound it is.

[nikomatsakis]

Similarly, in ac1f84c, we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.

[thestinger]

Is this still an issue? It seems to be fixed now.

[nikomatsakis]

Still an issue with respect to type parameter bounds.

[pcwalton]

I don't believe this is backwards incompatible, renominating.

[graydon]

accepted for feature-complete milestone

[huonw]

The following appears to work, but I assume that this is what @thestinger was talking about:

trait Foo {
    unsafe fn x();
}

impl Foo for int {
    unsafe fn x() {}
}
impl Foo for uint {
    fn x() {}
}

fn main() {}

[metajack]

triage bump. nothing to add.

[pnkfelix]

Accepted for P-backcompat-lang

[nikomatsakis]

Added UPDATE to main bug description above.

[fhahn]

I had a look at this issue and tried to create a test case. @nikomatsakis does this test case covers the issue you mentioned?
This test case fails because it seems like the parameter types are checked in librustc/middle/typeck/check/vtable.rs

[flaper87]

@fhahn what error does it fail with? In the impl you need to use a different type bound for test_fn in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:

trait ParamTrait {}

struct Param;

impl ParamTrait for Param {}

struct Bar;

trait Foo {
    fn test_fn<T:Eq>(&self, x: T, y: T);
}

impl Foo for Bar {
    // The type param of the implementation is not
    // the same as specified in the trait `Foo` nor implied
    // by it.
    fn test_fn<T: ParamTrait>(&self, x: T, y: T) {}
}

fn main() {
    let x: Bar = Bar;
    x.test_fn(Param, Param);
}

[fhahn]

@flaper87 thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.