[GolDDranks]

I thing you are right about that, I'd prefer panicking too. Also, reading the RFC will surely clear up the motivation.

Without knowing this case, I'd wager a guess: it's about performance. Panicking introduces a branch and side-effects which, again, affects negstively optimization potential and performance. The saturating cast affects performance too, but less. If some old code has a lot of number crunching containing these operations, a big performance regression would be nasty.

[nicoburns]

I think the long-term plan is to deprecate `as` entirely (probably in a future edition). You will then be free to pick between a function that panics, one that gives you a Result, or that saturates, etc. I believe most if not all of these functions already exist.

[kd5bjo]

It looks like ‘as’ is generally defined as a truncating cast operator for other numeric types. Since it doesn’t panic for other overflow situations (like u64->u32), they chose consistency with those cases.

https://github.com/rust-lang/rust/issues/10184#issuecomment-...

[jfkebwjsbx]

It is't about performance because array indexing also panics.

[kibwen]

Compilers are better at eliding array index checks than about eliding numeric overflow checks; an ordinary function that operates on arrays will often be able to reasonably determine both the length of the array and the scope of the indexing variable (Rust's iterators are very good at this), whereas an ordinary math function often has almost no information that usefully limits which values it might be getting called with.

I don't disagree that making more obvious errors into panics would be nice, but the performance implications are often quite unforgiving.

[jfkebwjsbx]

They aren't unforgiving, because if you need performance you can use another function that does not do the check. Same as for arrays.

It seems strange to have a cast as a safe operation and yet return results that are almost surely a bug. This means I will avoid casts altogether in my code, and I do hope they get rid of them at some point as some have suggested.

[kibwen]

> They aren't unforgiving, because if you need performance you can use another function that does not do the check

Rust tries hard not to cause regressions in users without good cause, which includes avoiding runtime performance regressions. One of the reasons that this fix took so long was that benchmarking prospective solutions revealed unacceptable performance regressions in users, even those who were already "doing the right thing" by manually upholding the proper invariants (no NaN, and value within range). The tension is that something still needed to be done, because at the end of the day the Rust creed is still "no undefined behavior without `unsafe`".

> This means I will avoid casts altogether in my code

Indeed, this is hardly discouraged wherever possible. For converting, say, a u64 to a u8, use `foo.try_into()` in order to get a conversion that follows the usual Rust conventions around Result-based error-handling (which didn't exist back when `as` was first conceived, or when this bug was originally filed). Casting floating point types to integers is already a rather rare use case in the first place.