3 ms·

I feel like if that's your take, then things like array indexing or dividing by zero should never panic. Because running into those things at runtime is very ha

I feel like if that's your take, then things like array indexing or dividing by zero should never panic. Because running into those things at runtime is very hard to prevent (unless you have tooling for enforcing that statically?)

YorickPeterse 2y ago
There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, array indexing is done using one of two methods: - 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: [10, 20, 30].get(0) => 10 [10, 20, 30].get(42) => panic [10, 20, 30].opt(0) => Option.Some(10) [10, 20, 30].opt(42) => Option.None 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).
- dullcrisp 2y ago
  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.
- Too 2y ago
  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.
- Muximize 2y ago
  I think this is bad api design. The opt method should not exist, and the get method should return option.

YorickPeterse 2y ago

There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, array indexing is done using one of two methods: - 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: [10, 20, 30].get(0) => 10 [10, 20, 30].get(42) => panic [10, 20, 30].opt(0) => Option.Some(10) [10, 20, 30].opt(42) => Option.None 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).

dullcrisp 2y ago
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.
Too 2y ago
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.
Muximize 2y ago
I think this is bad api design. The opt method should not exist, and the get method should return option.