Warning

This post was published 34 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Precedence of ParamEnv

Hey folks,

I was thinking a while about issue #24066 the initial post of the issue mentions the following example:

trait Trait<T> {
    fn call_me(&self, x: T) {}
}
impl<T> Trait<u32> for T {}
impl<T> Trait<i32> for T {}
fn bug<T: Trait<U>, U>(x: T) {
    x.call_me(1u32);
    //~^ ERROR mismatched types
}

My personal gut feeling tells me that it's perfectly fine how it works today, because otherwise the body could further restrict the constraints from the function signature which would probably lead to even more confusion on the call site. I think a caller should be confident that his input will be accepted if it satisfies the constraints of the function signature.

But it seems to me that most people see this behaviour as an inadequacy oder even a bug therefore I would like to ask if I'm maybe completely wrong with my assessment?

Regards
keks

5 posts - 3 participants

Read full topic

🏷️ Rust_feed