Bikeshed: A consise verb for the `?` operator

[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); }

[MajorBreakfast]

I think “rethrow”, “propagate” and “bubble” don’t capture the conditionality aspect enough. “maybe” and “check” capture this aspect because these words suggest that it could go both ways.

[Centril]

I agree with you that it doesn’t capture that aspect in the word itself; however, I think it is sufficiently implied from the context it is used in and the symbol ? itself.

On the other hand maybe and check do not say what happen on “nothing” or “failure”. If you want to be fully unambiguous, I’d say: maybe rethrow, but that is a mouthful.

     foo, then maybe rethrow,
then bar, then maybe rethrow,
then baz, then maybe rethrow,
then biz, then maybe rethrow,
then buz

EDIT: if you want a short word, you will invariably not capture some aspect of the full operational semantics.

[MajorBreakfast]

I think that the check aspect should be reflected in the name because it decides what happens next. There are of course only two options: The result is ok or there’s an error.

Throwing only happens in case there is an error: The “re” in “rethrow” does not imply that it only throws if there was an error. Instead the word suggests that it assumes there to be an error which it can throw again.

I think the name should be a single word. I agree with you that it this will be not enough to describe its meaning fully. To me the checking which happens first and decides what happens next should be reflected in the name.

Some functions that return a result start with the try_ prefix. It makes sense to “check” after you “try” something. Same argument works for “maybe” as well: You “try” something and “maybe” it works. Both words are also sufficiently rarely used to make them practical.

Edit: And both of these words also fit nicely to the operator’s symbol the “?”.

[anatol1234]

I am in favor of taking a turbofish-approach for the ? operator. The behaviour of this operator apparently is just slightly too complex to capture it with a single consise verb. Moreover, turbofish has already opened up the opportunity for a goofy naming scheme. I would even go a step further and propose to utilize the mnemonic link system (Mnemonics are frequently used in marketing). The mnemonic link system is an effective method for remembering lists of things or sequences of actions, which may also contain branches.

For example, when memorizing the list (dog, envelope, thirteen, yarn, window), one could create a story about a “dog stuck in an envelope, mailed to an unlucky thirteen black cat playing with yarn by the window”. It is argued that the story would be easier to remember than the list itself.

The behaviour of ? could be translated to a story using this method and finally be linked to a single word. The rationale is this: It does not really matter if the word itself does not capture any aspect of ? at all. A user has to look up the exact meaning at least once the first time he comes across a ? anyway. Whatever information he finds when looking up the meaning of ? should establish a strong long-term link between ? and the exact behaviour of ?.

Here is an example based on a fairy tale:

• Cinderella - “The good ones go into the pot, the bad ones go into your crop”

The beautiful thing about Cinderella is that it also captures the aspect of the From::from function being applied in the error case: When picking up a lentil (Result) a pigeon (?) must consider two options. If the lentil is a good one (Ok), the pigeon simply puts it into the pot (evaluates to the wrapped value). However, if the lentil happens to be a bad one (Err), the pigeon eats it, digests it (from) and finally “returns” it. Also the silhouette of a pigeon kind of resembles a questionmark.

[scottmcm]

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

Note that the first post in this thread references that name:

So I guess the official name is the “explicit exception propagation operator”, but that’s a bit of a mouthful and a poor trait name.

[illustrious-you]

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.”

If, when reading ?, you reach for conjunctions (then) and other adverbs (maybe), then why identify it with a verb?

[Centril]

then stands for function application here.