Bikeshed: A consise verb for the `?` operator

[illustrious-you]

@steven099

It seems like, if ’break with value’ is a general feature, and there’s Ok wrapping, then break should actually represent the success case.

I don’t know of a case where break does ok-wrapping.

In which case, you want something really clear like fail to represent the error case (fail matches try {}).

With fail, and a new keyword pass for ok-wrapping:

let _: Result<Foo, Bar> = routine {
    foo()?;           // ? operator
    fail Bar(0);      // assign Err(Bar(0)) to _
    fail Baz(0);      // assigns Err(Bar(x)) to _ after error conversion
    pass Foo(0);      // assign Ok(Foo(0)) to _
    Foo(0)            // assign Ok(Foo(0)) to _
}
// ...

This seems to have worse cohesion than the earlier blocks, I can’t think of a name for ? in this pattern, and it explicitly returns to an error handling construct. On the other hand, it can’t be argued that it behaves anything like traditional exceptions.

There may be a way to tie in with the pass/fail terms:

let _: Result<Foo, Bar> = eval { // like "evaluation"
    foo()?;       // try operator
    fail Bar(0);     
    pass Foo(0); 
    Foo(0)          
}
// ...

Since evaluate and try have similar meaning in this context, they can be swapped:

let _: Result<Foo, Bar> = try {
    foo()?;       // evaluate operator
    fail Bar(0);    
    pass Foo(0);
    Foo(0)         
}
// ...

[steven099]

I don’t know of a case where break does ok-wrapping.

There isn’t anywhere that does ok-wrapping. If catch (or try or…) and maybe certain functions were to do ok-wrapping, it would be something that happens at the block/function boundary. break represents a block boundary, and thus it would make sense for ok-wrapping to happen there.

I can’t think of a name for ? in this pattern

Again, I like catch { ... } with throw, where ? can be ‘try’. But for try { ... } with fail, then ? can be ‘branch’ or ‘maybe’ or something.

[illustrious-you]

let _: Result<Foo, Bar> = catch {
    foo()?;          // try or bubble?
    fail Bar(0);     // break w/ err-wrapping, replaces throw
    fail Baz(0);    // like `goto handle` w/ handle identified via pattern match.
    pass Foo(0);     // break w/ ok-wrapping
    Foo(0)           // implicit ok-wrapping
}
handle Baz(0) {      // must break with either Ok(Foo) or Err(Bar)
    fail Biz(1);     // break with Err-wrapping
    pass Foo(1);     // break with Ok-wrapping
    Ok(Foo(2))       // return explicit value (no ok-wrapping)
}

And the eval-based example:

let _: Result<Foo, Bar> = eval { // like "evaluation"
    foo()?;         // try operator
    fail Bar(0);    // break w/ err-wrapping, replaces throw
    fail Baz(0);    // like `goto handle` w/ handle identified via pattern match.
    pass Foo(0);    // break w/ ok-wrapping
    Foo(0)          // implicit Ok-wrapping
}
handle Baz(0) {      // must break with either Ok(Foo) or Err(Bar)
    fail Biz(1);     // break with Err-wrapping
    pass Foo(1);     // break with Ok-wrapping
    Ok(Foo(2))       // return explicit value (no ok-wrapping)
}

I believe the handle semantics could be useful in solving the problem RFC 243 points out about match sugar:

There was some concern about potential user confusion about two aspects:

• catch { } yields a Result<T,E> but catch { } match { } yields just T;
• catch { } match { } handles all kinds of errors, unlike try/catch in other languages which let you pick and choose.

The handle logic presented above runs on fail, and can pattern match on the type of any fail, but they must return a value consistent with the statement’s type (in the above examples, handlers must return Result<Foo, Bar>). The fail and pass shortcuts are still available, but fail handlers don’t recurse, so the type returned in fail must have a std::convert::From implementation to the expression’s failure type.

[scottmcm]

bubble because it bubbles errors. I also thought bail was a decent choice, but sounds a little scary. At least bubble has a very friendly rainbows-and-unicorns feel.

TBH, I laughed when I read that the first time. But now I love it

It’s pronounceable & distinctive. But more importantly, it actually manages to imply both conditional and propagation, while most of the others (vomit, halt, …) only imply “it failed” to me.

[160R]

I use it to ensure that value is not error

[uberjay]

A post in the dedicated operators thread has me thinking about ? some more. A thought experiment – if ? were allowed to be a user-defined trait, what would it be called? For me, I keep coming back to verbs which have a nice adjectival form:

• check, checked, checked expression, Check trait
• guard, guarded, guarded expression, Guard trait

I actually really like check. To my ears, it carries the feeling of “open and examine for correctness”, while also being terse and work well in adjective form. Guard, on the other hand, doesn’t carry that sense of examining to me. (and probably conflates the issue with guard clauses, if they were to come along.)

Other interesting verbs like check that come to mind: vet, verify, examine, inspect.

impl Check for Result {
    fn check(self) {
        match self {
            Err(e) => return 'super Err(e.into()),
            Ok(v) => v
        }
    }
}

(imagine, for the purpose of this experiment that the check function could actually return from the enclosing scope. Perhaps if traits could implement macros?)

NB: I am pretty new to Rust, so take this for what it’s worth! I guess that could be a positive or a negative, depending on your perspective!

[zrk]

Not a verb, but I’d read it as please?.

fn main() -> std::io::Result<()> {
    // Create "foo.txt", please?
    let mut file = File::create("foo.txt")?;
    // Write "Hello World!" to it, please?
    file.write_all(b"Hello, world!")?;
    Ok(())
}

It makes sense to me that it wouldn’t be a verb, because verbs are for methods/function. The please? operator qualifies the action that’s taking place.

Granted, this doesn’t convey the “propagation” part of the story, that bubble does very well.

[steven099]

(imagine, for the purpose of this experiment that the check function could actually return from the enclosing scope. Perhaps if traits could implement macros?)

Rust currently uses a trait called Try (the name coming from calling ? ‘try’ after the try!(...) macro). It really only abstracts over success and failure, with the compiler generating the necessary control flow. It could probably be called “check” if that was what we decided to call ?.

Member macros is an interesting idea, though problematic since it requires type resolution to happen before code generation, which might in turn affect type resolution etc… Another approach would be to have a return type which encapsulates imperative effects, like return, break, etc… So you could escape a block of code and return it (pseudocode):

impl<T, E> Check<T> for Result<T, E> {
    fn check<C, RT, RE>(self) -> impl Command<T, C>
    where 
        C: ImperativeContext<Return=Result<RT, RE>>,
        E: Into<RE>,
    {
        escape {
            match self {
                Err(e) => return Err(e.into()),
                Ok(v) => v
            }
        }
    }
}

and then run it in a caller. The names and overall design are obviously just placeholders to communicate the idea.

[MajorBreakfast]

How about making finding an official name for this a goal for Rust 2018?

I just read through the thread. Here is my personal short list:

• check
• maybe
• try

[Centril]

How about making finding an official name for this a goal for Rust 2018?

…Must …Resist …Urge …To …Bikeshed…

[Soni]

I like “propagate” because it’s not about exception/error handling.

It’s about propagation:

fn whelp() -> Option<X> {
   a?.b?.c?.d?.e // assuming e is an Option<X>. otherwise put an .into() on it
}

[repax]

I don’t know… You can say that whelp failed to produce an X. I see them as conditional failure points.

The beauty of ? is that it’s quick and easy to find the possible points of failure of a fn without them being distracting.

[illustrious-you]

I was reading the PreRFC for catching functions when a link posted by @scottmcm caught my eye: Exceptional Syntax - Microsoft Reserarch

The paper called ? “unless”. Though it’s not a verb–it’s a conjunction–it presents a concise word that’s a reasonable shorthand of the control flow: “continue unless {fn} returns an error”.

[lordan]

… did someone say “bikeshed”? Anyway, this would be my suggestions:

• ensure, or conversely:
• diverge

[IsaacWoods]

diverge

Hmm, since a function of type fn(...) -> ! is known as a diverging function already, this doesn’t seem like a great choice

[lordan]

Good point! In that case I’d change my suggestion to

• bail

as a suggestion if we want to emphasize the “aborting” nature.

[scottmcm]

The paper called ? “unless”

The paper is in SML, which has implicitly-propagated exceptions, so doesn’t contain a name for ? at all, as the operator doesn’t exist. It uses unless for what’s basically catch. Its

let x = A;
in B(x)
unless C => D

is essentially

match try { A } {
    Ok(x) => B(x),
    Err(C) => D,
}

Also, I think .foo()?.bar() reads poorly as “unless”, since you get “foo unless bar”, which grammatically I would interpret very differently.

In that case I’d change my suggestion to bail

bail is what failure is currently using for throw: https://docs.rs/failure/0.1.1/failure/macro.bail.html

[xfix]

I usually call it “question mark operator”, and in fact if you try searching for “question mark operator rust” with your favorite search engine, you will find results for it.

An unoriginal name, sure, but nobody suggested it, and I would wager a guess that most Rust programmers would quickly figure out what “question mark operator” means when seeing somebody use this name.

[illustrious-you]

Also, I think .foo()?.bar() reads poorly as “unless”, since you get “foo unless bar”, which grammatically I would interpret very differently.

I agree, reading the code and substituting “unless” doesn’t work. Perhaps the key insight is that we should consider conjunctions in addition to verbs.

• So
• Thus
• Therefore
• Ergo
• Hence
• Consequently

“Ergo” has a punny quality to it that might serve as a useful mnemonic – “on Err go”.

(Conicidentally, “ergo-” is also a combining form of “ergot”. Both ergot and rust are fungal plant diseases.)

[Centril]

If I’d read foo.bar()?.baz()?.biz()?.buz() out loud I’d say:

“foo, then maybe bar, then maybe baz, then maybe biz, then maybe buz.”

or just (pretending that ? isn’t there…):

“foo, then bar, then baz, *then biz, then buz”

But I think so far the best proposals have been:

• rethrow (which is exactly what it does, it matches the operational semantics perfectly).
• propagate
• bubble

In conclusion, I think it should be called rethrow because:

expr? ==  match expr.into_result() { Ok(o) => o, Err(e) => throw!(e); }