Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The short answer is that both values and errors are usually better scoped to only the places where they should be used.

For one, Rust's unwrapping of values is done in one step, as opposed to a "check first, unwrap second".

    if let Some(inner_value) = wrapped_value {
        // ..do something with inner_value..
    }
Or this:

    let Some(inner_value) = wrapped_value else {
        // compiler forces this branch to divert (return, break, etc)
    };

    // ..do something with inner_value..
This makes it so you can't check something and unwrap something else.

Second, for pulling out errors, you would usually use a match statement:

    match my_result {
        Ok(good_value) => {
            // use the good_value; the bad_value is not available here
        }
        Err(bad_value) => {
            // use the bad_value; the good_value is not available here
        }
    }
Or:

    let good_value = match my_result {
        Ok(good_value) => good_value,
        Err(bad_value) => { /* return an error */ },
    };

    // bad_value no longer available here
This makes it so that you can't invert the check. As in, you can't accidentally check that it's an Err value and then use it as an Ok, because its inner value won't be in scope.

You also can't use an Ok value as an Err one beyond its scope, because the scope of the error and the scope of the good value are a lot more limited by how if let and match work.

What the C++ code is doing is repeatedly calling `value.unwrap()` or `value.unwrap_err()` everywhere, pinky-promising that the check for it has been done correctly above. There's some clever checks on the C++ side to make this blow up in bad cases, but they weren't enough.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: