Same trait with different input concrete parameters are considered duplicate bounds (`: Bound<i8> + Bound<u8>`)

[japaric]

STR

#![crate_type = "lib"]

pub trait Bound<T> {}
pub trait Trait: Bound<i8> + Bound<u8> {}
//~^ error: trait `Bound<u8>` already appears in the list of bounds
fn foo<T: Bound<i8> + Bound<u8>>() {}
//~^ error: trait `Bound<u8>` already appears in the list of bounds
fn foo<T>() where T: Bound<i8> + Bound<u8> {}  // OK

Due to multidispatch : Bound<i8> + Bound<u8> is a valid bound, but the compiler is rejecting it in some positions (supertraits and bounds in parameter list), but not in others (where clauses)

Workaround for the supertrait

You can use dummy intermediate traits to indirectly add the "duplicate" bounds, but this is very verbose.

pub trait Bound<T> {}
pub trait Dummy: Bound<i8> {}
pub trait Trait: Dummy + Bound<u8> {}  // `Trait` implies `Bound<i8> + Bound<u8>`

Version

rustc 1.0.0-nightly (3ef8ff1f8 2015-02-12 00:38:24 +0000)

cc @nikomatsakis

Originally reported in #18693 (Niko preferred opening a new issue, instead of re-opening the old one and modifying the original report)

[nikomatsakis]

This was an intentional limitation, but it really doesn't make a lot of sense in a multidispatch world, and is also often something you can workaround with where clauses.

[jroesch]

@nikomatsakis it seems like if we commit to the supertrait/bounds changes that I started this should no longer be an issue since all bounds end up being checked by a single code path. Just an observation.

[nikomatsakis]

I've wound up fixing this as part of another patch (partly due to what @jroesch was saying).

[jroesch]

👍