E0122 says bounds aren't enforced, but they actually are?

[clarfonthey]

For multistr I've included trait bounds in type aliases so that it's clear in the documentation what should be passed to the generics for these aliases, e.g. SliceArray5.

But because I've generated several of these aliases E0122 floods my error output and I don't see any way of turning it off:

warning[E0122]: trait bounds are not (yet) enforced in type definitions
   --> src/array.rs:166:13
    |
166 |             pub type $slice_name<T: 'static + Copy> = $name<[T]>;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

(× 17)

It'd be really nice if I could silence this error somehow, because while it's good to have the error by default, it's making debugging my code very hard when I have to scroll past a wall of these errors.

[nagisa]

Future compatibility warnings are made explicitly un"turn-off"able exactly because people "turn-off" them and then when stable version making it a hard error releases, complain on rust-lang/rust that their code was broken without any prior warning.

[durka]

How hard is it to enforce trait bounds in type aliases?

[Kixunil]

I've run into similar issue recently. What's weird is that compiler actually does enforce trait bounds in type aliases, at least in this case. If you try to compile the example, you'll see that compiler contradicts itself. I can't imagine a universe in which it isn't a bug.

[jsgf]

In my case I want to use a trait's associated types, so the type bound is unavoidable:

type CacheHash<F: Filler> = BoundedHash<F::Key, Slot<<F::Value as IntoFuture>::Future>>;

For this use the message is pure noise.

And as @Kixunil mentioned: it looks like the bound is enforced:

trait Foo {
    type Bar;
    type Biff;
}

type Thing<F: Foo> = (F::Bar, F::Biff);

fn main() {
    let v: Thing<u32> = unimplemented!();
}

fails to compile with:

rustc 1.17.0 (56124baa9 2017-04-24)
warning[E0122]: trait bounds are not (yet) enforced in type definitions
 --> <anon>:6:1
  |
6 | type Thing<F: Foo> = (F::Bar, F::Biff);
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0277]: the trait bound `u32: Foo` is not satisfied
 --> <anon>:9:12
  |
9 |     let v: Thing<u32> = unimplemented!();
  |            ^^^^^^^^^^ the trait `Foo` is not implemented for `u32`

error: aborting due to previous error

Playground: https://play.rust-lang.org/?gist=85d34e30da9c6ba78893fd885ab05547

[durka]

Shockingly, you're allowed to make a type alias using associated types without declaring the bounds:

type Foo<I> = Box<<I as Iterator>::Item>;

[jsgf]

Oh, interesting! I hadn't considered that variation.

[jsgf]

I think the message is referring to the fact that you can do something like this without raising an error:

trait Thing {}

type Alias<T: Thing> = (T);

type Bad = Alias<i32>; // i32 doesn't implement Thing, but no error

You do get an error if Bad is actually used though.

[Kixunil]

@durka Interesting. Seems like the best way to turn off that message is to remove the bound and put it into doc comment.

[johncf]

Any plans for actually enforcing these bounds soon?

Future compatibility warnings are made explicitly un"turn-off"able exactly because people "turn-off" them and then when stable version making it a hard error releases, complain on rust-lang/rust that their code was broken without any prior warning.

In most cases, objects which don't satisfy those bounds cannot be created (due to other bounds). I don't think this is significant enough to put Rust's stability guarantees at risk. So please make these warnings suppress-able, if this is at low priority for being implemented.