Nikolai Vazquez

@skade Added [`assert_impl`](https://docs.rs/static_assertions/0.2.2/static_assertions/#assert-trait-impl), which is in release [v0.2.2](https://github.com/nvzqz/static-assertions-rs/releases/tag/v0.2.2) 🎉

There was some form of doing this that @kennytm recommend me. I don't exactly remember what it was.

@matthiasbeyer This would likely have to be implemented as a procedural macro. In that case, both parameters would have to be string literals. I'm curious if this could be done...

@jendrikw I finally decided to close #9 with 1f470d2a0d6197214a748481265625e6e678ec62. It produces a rather nice error message: ``` error[E0308]: mismatched types --> tests/eq_ty.rs:12:5 | 12 | assert_eq_type!(byte; super::X, u8, usize, (super::X));...

@DrSensor the 1.0 beta is coming out soon. I'm dealing with life stuff which is why it hasn't come out yet. I tried getting around to it when 1.37 came...

Aren't nalgebra's compile-time errors done via trait constraints? Can you provide examples of their errors and possibly how they're emitted?

There's no way of making `#[cfg]` work with constant expressions. As far as I know, `compile_error!` can only be conditionally used with `#[cfg]`.

As @memoryruins pointed out to me, apparently `typeof` is already a reserved keyword as seen in [`issue-42060.rs`](https://github.com/rust-lang/rust/blob/0f11354a9c1bf0c5ac250c7fa2bafc289a662f42/src/test/ui/issues/issue-42060.rs) and [`issue-29184.rs`](https://github.com/rust-lang/rust/blob/9ebf47851a357faa4cd97f4b1dc7835f6376e639/src/test/ui/issues/issue-29184.rs). However, I think the above proposal is a more elegant approach...

You bring up a very good point. I suppose `{expr}.type` would be fine in the meantime but that is quite awkward. Do you know what work is being done right...

In the macro example I gave, would that work without needing `{$x}.type` since the parser knows that the tokens are being treated as an expression?