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!

[nixpulvis]

Unless I'm missing something, this isn't a huge problem because bad things will still fail to type check right? For example the following doesn't compile.

trait Foo {
    fn foo(&self) -> u32 {
        1
    }
}

type Bar<F: Foo> = F;

fn foo(f: Bar<&str>) -> Bar<&str> {
    f
}

fn main() {
    let bar: Bar<&str> = "";
    println!("{:?}", foo(bar.foo()));
}

[pnkfelix]

@nixpulvis I think the argument for checking type definitions is analogous to our philosophy about other polymorphic code: we don't do C++ style post template-instantiation type-checking; instead we check the polymorphic code at the definition site (even though both strategies are sound)

Or maybe you are just saying the backwards incompatibility hit won't be that bad? (To which I say: famous last words. .. ;)

[nixpulvis]

@pnkfelix I was really just posting to confirm that I wasn't missing something. The warning sounds a bit scarier than it is in reality. I think this is tangental to #30503, as I do feel having type aliases which aren't check could be useful.

[nikomatsakis]

So this issue is a regular annoyance. It's worth trying to figure out just what we want to do, however!

The key problem is that type aliases are "invisible" to the type checker. You could almost just remove where-clauses from them altogether, but that we need them to resolve associated types in things like type Foo<I: Iterator> = I::Item. Interestingly, in cases like that, if in fact Foo<X> is applied to some type X where X: Iterator does not hold, the code should still fail to compile today, despite that warning that the trait bound is "unenforced". This is because the trait bound is implied by the type itself, which expands to <I as Iterator>::Item.

Enforcing all type bounds could be tricky, but may well be readily achievable. There is some backwards compatibility to worry about. I guess how we would implement it would be to extend the "item type" associated with a type item. This might be a small patch, actually.

Another option would be to detect if the bound is needed (i.e., consumed by an associated type), and warn only if that is not the case. That would just be accepting that we allow where-clauses here even when they are not needed and will not be unenforced. Doesn't feel very good though.

Seems like we might want to start by trying for the "better" fix, and then measuring the impact...?

[RReverser]

Interestingly, in cases like that, if in fact Foo is applied to some type X where X: Iterator does not hold, the code should still fail to compile today, despite that warning that the trait bound is "unenforced". This is because the trait bound is implied by the type itself, which expands to ::Item.

@nikomatsakis Would it be possible to remove that warning for these cases then? It's quite confusing.

[nikomatsakis]

@RReverser I agree. I just added a to do item to try and investigate disabling the warnings.

[nikomatsakis]

The best option I can think of currently is to make people write <T as Trait>::Assoc. That seems to be the best practice as of now. It is slightly surprising that you can use T as Trait without having T: Trait, but that is consistent with being able to write

Yes, that's probably the most forwards compatible thing you can do, and yes it's somewhat surprising (but consistent). I tend to make an alias in practice just so it is shorter (and to not get warnings):

type Assoc<T> = <T as Trait>::Assoc;
type SomethingElse<T> = Vec<Assoc<T>>;

[RalfJung]

(1) Implement lazy normalization (underway)
(2) In Epoch 2018 (hopefully we get this done in time...), handle type aliases not as "eagerly normalizing" in the type-checker, but rather as "lazy normalizing", just like an associated type

Yes, that's probably the most forwards compatible thing you can do, and yes it's somewhat surprising

Okay, so given that, do you think the approach I took in #48909 makes sense?

[nikomatsakis]

@RalfJung are you asking if your suggestion to use <T as Trait>::Foo form makes sense? I think it does, I mean -- as you said -- we can't exactly break that usage, at least not without some kind of opt-in, for back-compat reasons. I can take a look at the PR in terms of giving an improved suggestion.

[RalfJung]

@RalfJung are you asking if your suggestion to use ::Foo form makes sense?

Yes. Originally I intended this to be a step towards turning the lint into a hard error eventually, but of course if this gets implemented properly that's even better. :) I can't imagine how to implement this in a nice backwards-compatible way, but well, you seem to have some idea :D

[alexreg]

Any progress here lately? (Trying to have a go at implementing trait aliases here.)

CC @nikomatsakis

[WaffleLapkin]

Is there any chance this will be implemented in edition 2021?

[D3PSI]

this would be such a juicy feature, is there any chance this will ever be implemented?

[Skallwar]

I just encounter a case where depending on conditional compilation, my type alias could change but I wanted to make sure that whatever concrete type was chosen, at the end it will implement a trait. I posted about it here

I wanted to do something like this:

#[cfg(target_arch = "x86_64")]
type MyAlias: MyTrait = A;
#[cfg(target_arch = "riscv64")]
type MyAlias: MyTrait = B;

[fmease]

To give an update to the people subscribed to this issue, the (incomplete) feature lazy_type_alias implements the expected semantics for type aliases:

• where-clauses and bounds on type parameters of type aliases are enforced
• type aliases are checked for well-formedness
• where-clauses are trailing instead of leading just like with associated types (see also Proposal: Change syntax of where clauses on type aliases #89122)

The feature is nominated for stabilization in a future edition (202X). Its tracking issue #112792 basically supersedes this issue in my humble opinion. See also F-lazy_type_alias `#![feature(lazy_type_alias)]` .