Remove all panics from standard library

[coolCucumber-cat]

I think the use of all panics in the standard library should be removed, with the exception of panic specific things like unwrap, expect and unimplemented.

Panics have all the same problems as exceptions, the only difference is that they are uncatchable. They change the control flow of a program in an unexpected way and are completely hidden unless you know yourself where they are, like documentation. I find them very un-Rust-like in the sense that they are implicit and you can never be sure exactly how your program works. It gives the same feeling as having to watch out for exceptions and null pointers in other languages where you are always on the edge of your seat and have to keep all these possible footguns in mind.

The example I dislike the most is division by 0 and overflows, which panics even in production. This is the kind of thing that Rust was supposed to avoid. There is not a mention of it unless you look at the source code. Despite being documented, said documentation can only be found by looking at the source code. Panicing should not be so widespread and hidden, especially not in the standard library.

Other operations like println! and adding ints fail silently, just expand that to all arithmetic (divison by 0 can return 0). Everything else can use Result and Option. If it does need to panic, then just use unwrap.

This is will break things, so I suggest adding it to the 2024 edition.

Edit: exception is for when it is impossible for the program to continue running, like being out of memory.

Edit 2: issue now no longer addresses indexing.

[BurntSushi]

So to be clear, you're proposing that slice[i] be removed from Rust in the next edition? If so, this issue can be closed because it's a non-starter. It's never going to happen.

Editions aren't a license to do arbitrary breaking changes.

[coolCucumber-cat]

@BurntSushi

No, it should just return an Option or Result instead. If you want it to panic, you can unwrap.

If I did mean that, then the rest of my proposal can still go through.

And it's also not an arbitrary change.

[coolCucumber-cat]

@kennytm What's wrong with my suggestion? Feedback is appreciated.

[kennytm]

@coolCucumber-cat Edition is only designed for change syntax, once a std library interface is stabilized it is there forever.

That is, since u64::div(u64) returns u64 in Edition 2015, it will always return u64, not Option<u64> nor Result<u64, DivError> in edition 2999 as long as it is still called "Rust 1.8554" not "Rust 2.something".

That is the "arbitrary breaking change" called out by BurntSushi above.

[kennytm]

BTW you could force your binary to never able to panic by using https://docs.rs/no-panic/latest/no_panic/ which turns the panic call into a linker error.

[coolCucumber-cat]

@kennytm Ok, I wasn't aware of not allowing changes. Where does it say that?

I never said arithmetic should change its return type, that's what the checked operations do. I said that it simply shouldn't panic and instead return 0. I think you meant to say that indexing shouldn't its return value, not arithmetic.

And I said it wasn't arbitrary, not that it wasn't a breaking change. I even said that it would break things.

So currently, the only problem is indexing, which I can remove from this RFC.

[coolCucumber-cat]

@kennytm @BurntSushi I removed indexing from this issue. Are there any other problems that need to be addressed?

Arithmetic not panicing is not a breaking change, but it would cause some programs to behave differently. That is allowed though, right?

[kennytm]

@coolCucumber-cat

Ok, I wasn't aware of not allowing changes. Where does it say that?

https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md#negative-examples-what-edition-opt-ins-cant-do

I said that it simply shouldn't panic and instead return 0.

For integers x / 0 returning any concrete number is simply wrong (integers don't have NaN or ±Infinity)

If you need to ensure divide-by-zero never happens make your denominator use the NonZero type.

[Diggsey]

I find them very un-Rust-like in the sense that they are implicit and you can never be sure exactly how your program works.
I never said arithmetic should change its return type, that's what the checked operations do. I said that it simply shouldn't panic and instead return 0.

Returning zero would be very un-rustlike. Rust prioritizes the following:

Correct program > Panicking program > Incorrect program > Undefined Behaviour

ie. a panicking program is better than an incorrect program, so making arithmetic operations incorrectly return 0 would make things worse.

[coolCucumber-cat]

In my opinion, returning 0 isn't incorrect. NaN for floating points has similar behaviour, but isn't considered incorrect. Neither is an overflow. I just don't see how panicking is better than a silent failure or what could break by instead returning 0.

You can consider division by 0 being 0 because anything divided by 0 makes infinity, which overflows to make 0.

[coolCucumber-cat]

Can you give an example where 0 would be worse than panicking?

[Diggsey]

You can consider division by 0 being 0 because anything divided by 0 makes infinity, which overflows to make 0.

And in debug builds Rust panics on overflow, because it's an error. It would do so in release to if it weren't for the performance cost of checking it.

Can you give an example where 0 would be worse than panicking?

In any situation where you actually want a correct answer? If you end up dividing by zero it means something has gone wrong earlier in the program. It's better to panic than allow the program to continue and potientially do something completely unexpected.

[kennytm]

The only cases I know that x / 0 == 0 are

1. The Pony language, which actually have 3 division operators (x / 0 == 0, x /? 0 == error, x /~ 0 == undefined behavior). However x / 0.0 == ±inf.
2. Provers like Lean and Coq because they require the function to be total and divide-by-zero shouldn't happen in the domain the proof should be working on (they also sort-of defined 100 - 250 == 0 for unsigned numbers).

[coolCucumber-cat]

I agree with what the Pony language has done: "So, in order to maintain a practical API and avoid undefined behaviour, normal division on integers in Pony is defined to be 0.".

When you divide by 0 with a floating point number, it produces NaN, which is not correct either. So if that's allowed then 0 can just be the equivalent of NaN but for ints.

In dev mode I think it should panic, as it does now, but in production I don't think it should because it doesn't even help you catch the error. Whoever is running your program will just get a random error that probably doesn't matter.

[kennytm]

When you divide by 0 with a floating point number, it produces NaN, which is not correct either.

No you get +Infinity if x > 0, -Infinity if x < 0 and NaN otherwise.

This is correct in the context of float as in conforming to IEEE 754.

So if that's allowed then 0 can just be the equivalent of NaN but for ints.

Except that NaN is not 0 (nor ±∞) in float

---

In any case redefining x / 0 to return 0 today is a breaking change of runtime behavior according to #1105 since the contract to panic is documented already.