What if we extend the .? operator to work with Enums, expecially for Errors

[peperronii]

Right now we have the .? operator that works with unions with 1 variant ( Almost exclusively for Maybe($T) ) which returns two values: the underlying value of that type, and a bool which will be true if the union does not equal to nil.

What if we just pull the bool checking from .? to use with Enums so now we can do stuff like:

Err :: enum {
     .None,
     .Oops,
     .Crikey,
}

get_some_int :: proc() -> (int, Err) {...}

main :: proc() {
    i, err := get_some_int()
    if err.? {
        fmt.print(err, "Something Went Wrong!")
    }
}

I think this will help with the boilerplate "err != nil" and also make the .? more usable. Me personally I don't mind the err != nil syntax and think that the error control flow is already great without the try/catch or stuff like that. The only problem I see with this approach is the readability (only for the first time exposing to this) and also the .? would be less orthogonal.

Thoughts?

[flysand7]

This syntactic change would make you type less characters when handling errors, but beyond that there's little value in it. You still have to write the if statement. You still have to perform the same handling. You just type it a little differently.

So really, there isn't logically different from what we were doing before, it's just syntax sugar for the sake of optimizing typing extra 5 characters. These types of changes don't affect readability too much (except for when people start preferring one way of doing things over the other and suddenly it's not so easy to skim the code for the error handling snippets), and their sole purpose is to allow you to type less. If you type fast, you don't really care, because you aren't saving much time. If you type slow, you still don't care because at the end most of the time you spend on programming is spend thinking, and if you're not making the logic easy, you're not optimizing that thinking time.

This is in contrast to what union types do: If you have one value in a discriminated union, what is being implemented is not a "type-discriminated union", but a "thing that either holds a value or doesn't". The focus in logic shifts, which is why the syntax is allowed to change form in these cases. You are now being allowed by the language, to think not of which variant the union has, but whether it has a value or not. This isn't just a syntactic change, it has a shift in logic, allowing you to write shorter code while thinking less about it.

---

That said, we kind of already have a thing that helps with err != nil boilerplate -- or_return, or_continue, or_break and or_else. These are useful operators to propagate errors or do some actions on them.

do_stuff :: proc() -> (value: int, err: Error) {
  value = do_other_stuff() or_return
  return value, nil
}

Unfortunately yes, if there is an error you can't easily get it back with these operators and do something like fmt.panicf to print it. You would need to write the if statement.

[peperronii]

I mean most of the points you've made could also be applied to
or_return, or_continue, or_break, or_else
but ofcourse .? literally just save 5 characters so i digress

This is in contrast to what union types do: If you have one value in a discriminated union, what is being implemented is not a "type-discriminated union", but a "thing that either holds a value or doesn't". The focus in logic shifts, which is why the syntax is allowed to change form in these cases. You are now being allowed by the language, to think not of which variant the union has, but whether it has a value or not.

But this does make me curious a lot about the actual thought behind union's .? becuase it only works with union with "1 variant" (Maybe(T)) so even though other unions have the zero value of nil we can't use .? to check if it holds value or not. It is even stated that it is barely used in the core library due to the fact that the language has multiple returns, but even so, it has its own syntax sugar.

[flysand7]

or_return et al., can also be used to avoid declaring the err value more than once in a procedure call.

Consider:

value, err := get_value()
if err != nil {
   return {}, err
}

versus:

value := get_value() or_return

It doesn't just save typing, but also reduces the need to write the if statement, and the declaration of the err variable. Just one less value to deal with and 3 less lines of code to read every time one handles errors.

Though maybe you are somewhat right that it's still about saving typing, in which case I'd just say there probably is a spectrum of "how much is this useful" versus "how much extra stuff do we want to add to the language". Because if one feature gets a little syntactic sugar like this, why not the others? That's a type of decision that makes languages
very large and harder to approach for beginners. Look no further than TypeScript that has at least 3 ways to define any type with wildly different syntax. That's not "a type", it's "any type".

It is even stated that it is barely used in the core library

There are many things the core library doesn't do that are somewhat allowed in the user code. Maybe(T) is one of them. My interpretation of this is that while Odin's error handling philosophy isn't designed around wrapped values, like in Rust, it is possible to implement them if your application would benefit from it more.

[gingerBill]

No.

.? already has a specific meaning to be a shorthand for an inferred type assertion.

Also, did you really suggest err.? over err != nil because the former is 5 characters shorter?

[peperronii]

Yes, i kinda did.