# Panic bounds in the type system level for guaranteeing panic-free code **URL:** \ **Category:** language design\ **Created:** [November 23, 2023, 9:36pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911 "2023-11-23T21:36:54Z")\ **Posts on this page:** 7\ **Page:** 2
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [November 25, 2023, 9:33pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/21 "2023-11-25T21:33:00Z")
I'm going to have details on this somewhat soon đź‘€ Right now I've experimented with `deranged` to the extent the compiler allows. If I use `generic_const_exprs`, the door is opened to a lot of things. The main thing compiler integration is needed for is for values that don't neatly fit within a single type (200u8 + 100u8, for example).The compiler could choose the representation automatically. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [November 25, 2023, 10:20pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/22 "2023-11-25T22:20:48Z")
> [@jhpratt](#): > > The main thing compiler integration is needed for is for values that don't neatly fit within a single type (200u8 + 100u8, for example).The compiler could choose the representation automatically. I think it would be great to have an infinite-precision integer type that's only usable at compile-time. Then people can avoid needing to pick particular types in generic parameters when there's no particular one that makes sense. (Array lengths staying `usize` still makes sense, of course.) Then yeah, compiler support into the backend so LLVM can handle it smartly would be particularly cool. ---
**Author:** ![jhpratt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jhpratt/32/11640_2.png) [@jhpratt](https://internals.rust-lang.org/u/jhpratt)\ **Post date:** [November 26, 2023, 1:34am UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/23 "2023-11-26T01:34:54Z")
First thing is to get finite-precision values in general, namely those that fit in `u128`/`i128`. ---
**Author:** ![rkuhn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/rkuhn/32/6659_2.png) [@rkuhn](https://internals.rust-lang.org/u/rkuhn)\ **Post date:** [November 26, 2023, 1:40pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/25 "2023-11-26T13:40:15Z")
Sorry, I’m late to the game: I think the previous discussion — interesting as it may be on a type level — misses a crucial point. When going for something absolute like “panic-free”, we should note that whatever properties the Rust type checker can prove about some program, this program can still fail because the assumed evaluation semantics of the language are not provided by the real execution environment. For example, stack and heap size are both limited. In the latter case, we could flag all possible allocations as potentially panicking, which would limit the usefulness of this rather intrusive feature to a tiny subset of all usage. In the former case, we have no such possibility. In my opinion, writing code that “must not ever fail” can only be done in a total language. The result is then run on proven deterministic infrastructure. To my knowledge, none of these are goals of the Rust ecosystem. ---
**Author:** ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)\ **Post date:** [November 26, 2023, 2:56pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/26 "2023-11-26T14:56:06Z")
> [@rkuhn](#): > > In my opinion, writing code that “must not ever fail” can only be done in a total language. The result is then run on proven deterministic infrastructure. To my knowledge, none of these are goals of the Rust ecosystem. I agree that such guarantees are outside of Rust's purview. I call the services like this "bulletproof" because, while it is fine against "small arms fire", it is definitely not immune to larger things like power cuts, network deliverability issues, and `root` access to the host machine. Personally, I think something like `panic=disallow` where the linker makes sure that no panic hook calls are made would be sufficient (though it leaves it to the linker rather than the compiler), but I also have only needed "bulletproof" guarantees, not "life-threatening" levels. Given that the latter does exist and uses languages less strict than Rust, I feel like there are development practices and patterns that can be employed for Rust as well even without sweeping new-marker-trait changes to the language itself. ---
**Author:** ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)\ **Post date:** [November 26, 2023, 4:51pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/27 "2023-11-26T16:51:37Z")
To me, there is value in verified panic-free code not specifically for guarantees of run-time reliability, but rather to know that _I have successfully written a total function,_ a function that has no unaccounted-for edge cases where it would panic. Of course this is not a guarantee of correctness, because it doesn't exclude stack overflow, infinite loops, or returning the wrong answer. But **reducing the number of cases** one needs to consider to evaluate whether code is correct is, in general, something Rust already does a lot of (such as memory safety and default non-nullable pointer types) and thereby provides value to its users. It may still be too impractical to actually work under such a restriction, of course. But note that the popular examples of difficulty of eliminating panic branches are indexing and arithmetic — and there are plenty of functions that contain no indexing or arithmetic. (Perhaps I should try programming with [no\_panic - Rust](https://docs.rs/no-panic) and see how bad it is…) ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [February 24, 2024, 4:51pm UTC](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911/28 "2024-02-24T16:51:42Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed. [Previous page](https://internals.rust-lang.org/t/panic-bounds-in-the-type-system-level-for-guaranteeing-panic-free-code/19911.md?page=1)