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.

[steveklabnik]

Triage: as far as I know, these warnings are not silence-able today.

[clarfonthey]

Checking the linked playground, and just off memory, I believe this error message has been removed? Is there anything left to do here?

[durka]

Looks like it is still there if you don't attempt to use the alias: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=c12b07f4ca88e40071ccfdbe2167e347

warning: bounds on generic parameters are not enforced in type aliases
  --> src/main.rs:10:16
   |
10 | type FooBar<F: Foo> = Bar<F, F::SomeType>;
   |                ^^^
   |
help: use fully disambiguated paths (i.e., `<T as Trait>::Assoc`) to refer to associated types in type aliases
  --> src/main.rs:10:30
   |
10 | type FooBar<F: Foo> = Bar<F, F::SomeType>;
   |                              ^^^^^^^^^^^
   = note: `#[warn(type_alias_bounds)]` on by default
help: the bound will not be checked when the type alias is used, and should be removed
   |
10 - type FooBar<F: Foo> = Bar<F, F::SomeType>;
10 + type FooBar<F> = Bar<F, F::SomeType>;
   |

It seems to me the compiler is not enforcing the bounds in the alias.

Rather, it's enforcing implicit bounds that come from using a fully qualified associated type in the right side of the alias, as I noted above.

That is, if you remove the SomeType piece of the example, then the warning is true and the compiler will let you instantiate a FooBar<u32>. But even if you remove the F: Foo bound, and you use <F as Foo>::SomeType on the RHS, then you get a bounds error when trying to instantiate FooBar<u32>. This is weird to me; it seems like more of a C++ templates paradigm where you can hum merrily along until you try to instantiate your types and everything explodes -- and I like Rust better where the mistakes generally get caught at the beginning.

Circling back around to @steveklabnik's comment, the warnings are now silenceable with #[allow(type_alias_bounds)]. But I don't know that that closes this issue.

With compiler-colored glasses, the only issue is that we don't enforce bounds declared in type aliases (why though?), but it's definitely a confusing diagnostic situation in all of these cases.