Oli Scherer

> Are you referring to static or dynamic checks here? neither. What I mean is to relax the dynamic checks for constants referring to statics and only do the pattern...

> This approach poses the risk that patterns (or const generics) could use an "unsuited" const and forget to run the stricter check on it. For const generics, we must...

> Why would const generics not be able to point to immutable statics? So far I assumed const generics and patterns (with exhaustiveness checking) have basically the same soundness concern....

> If I understand correctly, in reality, Wrapper::::PTR is effectively just inlining &42 as *const u32, and it would be allowed to produce different values when evaluated multiple times even...

> Oh I see... so we allow pattern matching on raw pointer consts? But we don't allow them in const generics? That's... messy. :/ I think noone is very happy...

> My first thought on this is: I am not sure if it's worth trying to shoehorn ty::Const into this; that poor thing is already doing too many jobs. @eddyb...

> I am totally open to bikeshedding the names. ;) It's a bit more than just bikeshedding. I was informed that if we had two representations for the same `usize`...

One further idea how to restrict this even more is ```rust #[const_write = "foo.man"] const _: &[u8] = b"foomp"; // or some actual const eval ``` which dumps the bytes...

During a discussion @Centril and I found a few points that I should write down here: ## Why an attribute? The attribute on constant scheme is better than a `const...

## "Precedent" There's some precedent for this. On wasm, the `#[link_section]` attribute for static items will raw dump the bytes of the static into the chose section. This also forbids...