evaluatable bounds are fun uwu
We cannot ignore CTFE failures of constants used in the type system
An impl like this is considered exhaustive
If we were to ignore (): Trait<error>
, what are sensible values for the associated items of that type.
pretty clear stuff
- Without evaluatable bounds, errors during monomorphization are unavoidable
- reaching the evaluation limit HAS to be a hard error and cannot be guarded against
- same for recursion and size limits
why are constants used in the type system special
Constants used in expressions could simply panic
on use. Constants used in the type system cannot be ignored when detected.
questions, thoughts, other stuff
- is there a difference between constants used in the type system and constants simply used in expressions?
- generic constants in expressions are already allowed without evaluatable bounds
- and instead with post mon oerrors which is dumb it should be a runtime panic
- is it, why?
- "soundness" if its an abort it will be fine…
- or could just be done over an edition I guess..? idk
- also, people rely on that behavior for soundness, so changing it seems hard
- the why is because it means you cant ensure something is eavluated at compile time as an optimization without opting into a post mono error for code that might not actually even get run
- I actually wrote why that is fine
- gdi we should have writtin all of this down somewhere xd
- just make it a lint, why hard error?
people are stupid and silence lints they don't understand
previous discussions
associated consts wf https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/associated.20consts.20const.20wf
which builds on https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const.20wf.20bounds.20implementation