Is type-inference of number types in generics working properly?


#1

rustc 1.0.0-nightly (d3732a12e 2015-02-06 23:30:17 +0000)

A simple example illustrates this.

use std::num::Float;

struct Foo<T> {
    a: T,
}

impl<T: Float> Foo<T> {
    fn twice(&self) -> T {
        // self.a * 2.0
                // mismatched types:
                //  expected `T`,
                //     found `_`
                // (expected type parameter,
                //     found floating-point variable) [E0308]
        // let one = Float::one();
        // self.a * (one + one)
                // the type of this value must be known in this context
                // tests/lang.rs:696             self.a * (one + one)
        // let two: T = Float::one() + Float::one();
        // self.a * two
                // the type of this value must be known in this context
                // tests/lang.rs:699             let two: T = Float::one() + Float::one();

        // This actually works !
        let one: T = Float::one();
        self.a * (one + one); // ; added just to allow to proceed.

        // So does this !
        let two: T = Float::one() + <T as Float>::one();
        self.a * two
    }
}

Do you think this is an issue worth looking at ?. Also, there might already be a related issue on github, even though I am not quite sure these are the same things.

Personally I’d love to be able to use float and int literals in such a generic context, as using Float::* and Int::* all the time is very cumbersome, making the code less readable than it has to be. I have also described this in a related issue on github.