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.
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â.
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.
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.
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".
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.
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.
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 â?â.
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.
Anyway, this would be my suggestions: