Consider Different Error Handling Approach

[mcmah309]

I love the idea of a Rust compatible gc language. But one of the things I like about Rust is explicit error handling over try/catch. I understand the appeal of try/catch for fast iteration and I wonder if there is a middle ground. For this type of language, I don't think explicitly stating the error type matters. Thus something like anyhow's Result<T> would be a nice idea.

fn result(arg: str) -> Result<str>:

I think we could improve this further though. I really like Zig's error handling (! like Result and ? like Option). Thus it could look like

fn result(arg: str) -> !str:

Going a step further, if we went with this route, we could handle Option the same way

fn result_option(arg: str) -> !?str:

The above function essentially returns a Result<Option<str>>.

All this together we could make error handling really nice:

fn result_option(arg: str) -> !?str:
    # examples
    let x: !str = todo()
    let x: str = x! # yeet if error
    let x: ?str = todo()
    let x: str = x? # yeet if null
    let x: !?str = todo()
    let x: str = x!? # yeet if error or null
    return x

fn main():
    # Handle all cases
    let value: str = result_option("hello") catch:
        # Case when the error is of type `ErrorType`. The default error variable name is `error`. Alternative syntax if new name is needed `!(error_name: ErrorType)`.
        !(ErrorType):
            # Assume `ErrorType` has the field `error_type_str_field`
            error.error_type_str_field
        !:
            "Unknown"
        ?:
            "Null"
    # Catch shorthand
    let value: str = result_option("hello") catch "shorthand"
    # Catch shorthand with panic (like `.unwrap()`) 
    let value: str = result_option("hello") catch panic()
    # Only handle one case shorthand. Since `?` is not handled, `?` is preserved on the value
    let value: ?str = result_option("hello") catch ! "Unknown"
    # Only handle one case block shorthand
    let value: ?str = result_option("hello") catch !:
            "This is is for larger blocks"
    # Handling multiple cases together
    let value: str = result_option("hello") catch:
        !(ErrorType):
        ?:
            "specifc error or null"
        !:
            return 1 # Early return
}

These concepts also map well to Rust. If we ever expose calling otter functions from rust, this

fn result_option(arg: str) -> !?str:

would become something like the following on the rust side

fn result_option(arg: String) -> Result<Option<String>, Box<dyn Error + Send + Sync>>

[mcmah309]

Moved to issue #8