Bikeshed: A consise verb for the `?` operator

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

1 Like

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

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.

4 Likes

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. :wink:

     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.

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

1 Like

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.

1 Like

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

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

then stands for function application here.

I am aware that when framing ? as a monadic/applicative construct, the mechanism implementing then is bind.

What I don't understand is how you agree that, semantically,? operates like a conjunction ("then maybe"), but still prefer a verb. The verbs, in your illustration above, are bar(), baz(), etc.

This is doubly hard to reconcile with your argument that try/? is a "happy path" construct. Conjunctions pair well with the happy path, verbs do not.

Compare:

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

or

foo.bar, therefore baz, therefore biz, therefore buz

with your preferred nomenclature:

foo.bar rethrow, baz rethrow, biz rethrow, buz.

foo.bar propagate, baz propagate, biz propagate, buz.

foo.bar bubble, baz bubble, biz bubble, buz.

I agree that no single word will capture the full extent of the operation, but the above demonstration shows that a conjunction offers more clarity than a verb. The conjunction captures the conditionality of the construct, a quality unmatched by rethrow, propagate, or bubble.

1 Like

I have trouble reading the example code with conjunctions like therefore on the opposite side of the call site from the operator in question (pun intended).

foo.bar()?

foo, therefore bar

The ? operator is clearly in a suffix position, which implies the above reading is in some ways "backwards". It's like the dollar sign, which has always been something I've hated.

$100

One hundred dollars

Compare with temperatures:

21°C is 69.8°F

Twenty-one degrees Celsius is sixty-nine point eight degrees Fahrenheit

The point I'm trying to make is that dollars and degrees are neither conjunctions nor verbs. They are nouns. Guess what else is a noun? bubble

1 Like

I think bubble does well on conditionality, since in a technical context it makes me think of bubble sort, where elements "bubble up" to the appropriate level, like errors do with ?.

Whoops! That's an error on my part. I only meant to add "therefore" where the ?'s are in the original. I updated my examples. Thank you for pointing that out!

I think of it in similar terms, though instead of a bubble sort it's events bubbling up the DOM. I certainly like it the most of the verbs mentioned, but it made me feel uneasy and I wasn't aware of why until I read the exception paper I linked above. I think of ? as the "connective tissue" between fallible actions, much like a conjunction.

I tend not to mentally pronounce ?, but instead I read the expression it’s attached to with question intonation. So I might mentaly read try_thing(foo)? as “try_thing of foo?”, or mutex.lock()? as “mutex dot lock?” (kinda hard to express over text =P). Curious to hear if other folks do this.

Not that it helps give ? a name; personally, I when I read ? not attached to an expression I just mentally say “q”.

2 Likes

I also think about the DOM when I hear "bubble". In web programming it means that an event travels up the tree. There's nothing conditional about it. It just travels upwards. There's only ever one parent element and it travels until it either reaches the root or the propagation is manually stopped.


Let's focus on counter arguments. I'd like to hear some for "check". Various people said they like it, but the only counter argument that was mentioned so far was:

  • Why does it seem generic?
  • The boolean feeling comes probably form "checkboxes" or QA checks. However, those kind of associations are exactly what we what

For "maybe" there was:

I agree with both statements.

3 Likes

I’d probably call it the question-mark operator because that name corresponds directly to its appearance. It would probably also be the most obvious name to search for when trying to learn Rust.

I do like the word check as the verb for this operator, as in: “verify as to correctness”, and for the general connotation of “interrupting the current motion”.

When reading Rust code the ? can also be read as the interjection “check!”, meaning “all right!”. This highlights the happy path while giving a small pause.

5 Likes

"check" is the best name for the concept I've heard yet, whereas, "question mark operator" is the best name I've heard for naming the operator itself. I nominate:

  • Concept: Check
  • Name of Operator: Question Mark Operator

Sounds good to me.

3 Likes

What about the "gate" operator? The concept of having a gate/door that you can pass or be rejected from seems appropriate. As if ? was a bouncer at the door for the "happy path". Maybe "bouncer" operator could work as well.

EDIT: Also sounds like a purgatory where the distinction between good and bad is made :stuck_out_tongue:

Purge: In history, religion and political science, a purge is a removal of people who are considered undesirable by those in power from a government, another organization, their team owners, or society as a whole.

1 Like

This reminds me of the 2nd definition of limbo:

an uncertain period of awaiting a decision or resolution; an intermediate state or condition.

Though, when I think of a "limbo operator", I think of the competitive kind.

1 Like

Still ‘try operator’.