Oli Scherer

We can pattern match on all kind of references. It's just that right now only `&str` and `&[u8]` (and maybe `&[u8; N]`) are actually used for exhaustiveness. This means that...

> @oli-obk is this still true? My statement was meant for constants of reference type. All other constants have been doing exhaustive checking since quite some time.

The reason is that @ecstatic-morse ported my `if unleash` branches 1:1 into the new system, assuming I had reasonably vetted the previous logic. That was not the case, I just...

Nit: ```rust fn baz() -> [u8; unsafe { std::mem::transmute(size_of::()) }] // not well formed, for any `T` with `size_of::() > 3` the final value is not a valid bool. ```...

Yes, but we don't detect it in intermediate computations like when it's stored in a local variable but never returned.

> The problem with this definition is that it is uncheckable (except with major effort). The way that it is proposed to check this is very cheap: If it is...

> So basically this system punts the question of polymorphic constants? yes > We don't even define what well-formedness means for them, but we ensure that the context always assumes...

An `ICE` is a compiler bug, there is no input to the compiler that should ever trigger an ICE

Summary: we can change what "well formed constant" means, but when talking about well formed constants, it must be whatever the compiler currently accepts as well formed. We don't talk...

> What would [u8; 64 + align_of::() * 0] be then? Not well formed, unless `T` is monomorphic. We could change well formedness rules to accept that, as it has...