Trait bounds are not yet enforced in type definitions

[Marwes]

Opening an issue since I could not find any information on when/if this will be enforced. Would be really useful for some generalizing I am trying for parser-combinators which I can't do currently without complicating the API.

Specifically I'd like to use a trait bound in a type definition to access an associated type to avoid passing it seperately but due to this issue I simply get a compiler error.

Simplified code which exhibits the error:

trait Stream {
    type Item;
}

trait Parser {
    type Input: Stream;
}

fn test<T>(u: T) -> T
    where T: Parser {
    panic!()
}

type Res<I: Stream> = (I, <I as Stream>::Item);

impl <'a> Stream for &'a str { type Item = char; }
impl <I> Parser for fn (I) -> Res<I> where I: Stream { type Input = I; }

//Works
//fn f(_: &str) -> (&str, char) {

//Errors
fn f(_: &str) -> Res<&str> {
    panic!()
}

fn main() {
    let _ = test(f as fn (_) -> _);
}

[jroesch]

At first glance this is probably related to the internal messy-ness of bounds vs. where-clauses. I'm not sure if the predicate constraints for type aliases are propagated correctly. You should be able to use a newtype as a work around:

struct Res<I: Stream>((I, <I as Stream>::Item))

Seems to work just fine on playground with the newtype: http://is.gd/krOTZv.

cc @nikomatsakis

[Marwes]

I would use a newtype but since the type I want to define is a specialized Result type that isn't possible in my case. I didn't really mention that since it is tangential to the bug itself.

[tamird]

Looks like warnings are now generated for this case, but not consistently[0].

Should this be a compile-time error instead?

[0] #20222 (comment)

[Marwes]

What is the status on trait bounds in type definitions? I worked around it the best I could for combine but it won't be as clean as it could be until bounds are allowed.

[bluss]

Where bounds are allowed, they're not checked properly.

I'm using this one and it compiles from Rust 1.0 or later

pub type MapFn<I, B> where I: Iterator = iter::Map<I, fn(I::Item) -> B>;

[nikomatsakis]

Nominating for discussion. Seems like backcompat hazard we should consider trying to address with a feature gate.

[bluss]

Since the bounds provide writing types you couldn't do otherwise, they are very useful. A feature gate would be a breaking change without recourse(?).

[nikomatsakis]

triage: P-medium

I think this might be not that hard to fix though!