Re:The Inevitability of the Borrow Checker
by dullcrisp on Friday February 07, 2025 @11:20PM
(#42980353)
If panics can’t be handled at runtime they need to be impossible to introduce. Saying they just need to be fixed immediately might make sense for a project with a handful of developers but as others have said a major production system failing due to a panic wouldn’t be acceptable.
Re:The Inevitability of the Borrow Checker
by Too on Saturday February 08, 2025 @06:46AM
(#42982306)
With those two names it's rather inevitable that any beginner of the language will use the obvious sounding, but panic-inducing get.
That's not scalable if it's not possible to catch panics. If panics can't be handled they must only be caused by super corner 0.001% cases, not by fundamental things like dividing an integer or indexing an array.
- Array.get/Array.get_mut for when you want to panic on an out-of-bounds index
- Array.opt/Array.opt_mut for when you want an Option type, with it being a None for an out of bounds index
So for example:
This pattern is applied across the standard library where this makes sense, such that the developer can pick which option works best for their needs.There are a few places where we check for some input at runtime and panic if this is invalid, but this is limited to cases where there's simply no sensible alternative (e.g. providing a key with an invalid size to a ChaCha20 cipher).