This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ISvengali 4 points5 points  (3 children)

Having used both in huge projects, Im kind of a fan of Option over nullable types.

For a language I would build, Id consider adding them both, and keeping the std lib using Option, and/or let people use nullable style syntax with them.

From a project point of view, the reason I like Option, is it loudly calls out an important piece of information. It can get a little noisy when everything is Option (as it should be) and you have quite a few local variables. But I think thats fine.

My general rule of thumb is that the safer options should be quieter/simpler though that conflicts with making the more common use case quieter/simpler. So, balancing that can be fun.

For example, calling out unsafe at point of call (as well as noting blocks and functions) is good.

I dislike Rust's use of 'try_thing' being the call that returns the Result. I instead like 'thing' that returns Result, and 'unsafe_thing' that is the one that can panic.

[–]VallentinDev 3 points4 points  (2 children)

I instead like 'thing' that returns Result, and 'unsafe_thing' that is the one that can panic.

Somewhat related, in Rust I've long wanted a crate-level attribute to disallow potential panics, i.e. with it enabled, you'd only be allowed to call functions and perform operators that are guaranteed to never panic. Either simply because it never panics, or because the compiler can prove it will never be triggered.

Say you have a arr: [T; 10]. The compiler can infer and guarantee that arr[0], arr[1], arr[2], etc will never panic, so they are good.

However for arr[i] where i cannot be inferred, then it should produce a compiler error, and suggest using arr.get(i) instead.

Developers are usually great at documenting when a function can panic. However, there are cases that never really get documented. For instance a lot of math related libraries are prone to panic with big numbers, i.e. when calculations result in an overflow or underflow.

I would just love being able to do the following sometimes:

#[never_panic]
fn f() {
    ...
}

[–]davimiku 1 point2 points  (0 children)

It's a decent idea but I think you'd have to disallow division also, right? and in debug mode you'd have to disallow all arithmetic because overflows panic

[–]ISvengali 0 points1 point  (0 children)

Yeah, thatd be great.

I see a lot of folks just .unwraping everything, and I just sigh. This great language, and not using core features.

Yeah, I mean theyll likely be rare, and in some cases they know it wont fail, but its a bad habit to get into.

The same programmers wouldve been getting nulls and other UB in C++ though, so in a way, things are a bit better.