Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
japaric opened this issue Feb 13, 2015 · 4 comments
Assignees
Labels
A-type-system Area: Type system

Comments

@japaric
Copy link
Member

japaric commented Feb 13, 2015

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
Copy link
Contributor

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.

@steveklabnik steveklabnik added the A-type-system Area: Type system label Feb 13, 2015
@jroesch
Copy link
Member

jroesch commented Feb 14, 2015

@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 nikomatsakis self-assigned this Mar 3, 2015
@nikomatsakis
Copy link
Contributor

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

@jroesch
Copy link
Member

jroesch commented Mar 4, 2015

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

4 participants