Rename the `if_ok!` macro

[alexcrichton]

Removing io_error was bad enough, I didn't want to worry too much about naming this macro at the time. The name if_ok!() isn't fantastic, and we should probably rename it.

• try!() - short, succinct, but can possibly evoke the notion of try/catch exceptions from other languages
• ok!() - also short and succinct, but may not always be clear what it's doing.
• if_ok!() - works well for let statements, not always clear what it's doing though.

Some code that I think should be considered when naming this macro:

fn foo() -> io::IoResult<()> {
    if_ok!(some_function());

    let bar = if_ok!(some_function());

    if if_ok!(some_function()) {
        // ...
    }

    match if_ok!(some_function()) {
        // ...
    }
}

Nominating.

[wycats]

I think that try! is fine, given that it evokes try/catch from other languages.

The semantics of try in other languages is "run this code, and it might throw an exception". Without a catch block, that exception is propagated up the stack.

The semantics of the proposed try! here is "run this code, and it might return an error result. The error is propagated up the stack via Result.

I don't think it's important for the semantics to be identical; new Rust users know that Rust doesn't have exceptions, and the analogy is strong enough to put them on the right path.

[wycats]

Why I don't like if_ok!: In general, commonly used APIs should not be multiple words.

Why I don't like ok!: It has no semantic meaning on its own, and therefore users will not have an easy time forming an association with what the code is doing.

[brson]

Here's @alexcrichton's example written with try!

fn foo() -> io::IoResult<()> {
    try!(some_function());

    let bar = try!(some_function());

    if try!(some_function()) {
        // ...
    }

    match try!(some_function()) {
        // ...
    }
}

[brson]

We could rename task::try to something else to remove confusion. spawn_try, spawn_catch, spawn_result

[wycats]

FWIW: if try! seems like somewhat less common than let var = try!(expr) or match try!(some_expr).

[nikomatsakis]

I think I like try!, though clearly it's not much like try in other languages, in that it surrounds the things whose failures you do not want to catch, rather than those you do. But I still think it's in the same general spirit. Certainly feels better than ok! and if_ok!.

[sfackler]

or_return! is another possibility, though it's a bit long and would read better as the hypothetical r.read(buf).or_return!() instead of or_return!(r.read(buf)).

[kud1ing]

The example with check:

fn foo() -> io::IoResult<()> {
    check!(some_function());

    let bar = check!(some_function());

    if check!(some_function()) {
        // ...
    }

    match check!(some_function()) {
        // ...
    }
}

[lilyball]

My biggest complaint with try!() is that, when encountering it in code for the first time, it looks like it's going to catch task failure.

Of the 3, I think ok!() is the best, but I don't think it's particularly good in the absolute sense. Maybe just result!()?

fn foo() -> io::IoResult<()> {
    result!(some_function());

    let bar = result!(some_function());

    if result!(some_function()) {
        // ...
    }

    match result!(some_function()) {
        // ...
    }
}

It's not great either, but it doesn't have any preexisting semantic baggage, and for let and match statements it reads like "let bar be the result of some_function()". It also makes it obvious from the name that it has to do with Results.

[pnkfelix]

.