- Feature Name: `try_expr`
- Start Date: 2018-04-04
- RFC PR: [rust-lang/rfcs#2388](https://github.com/rust-lang/rfcs/pull/2388)
- Rust Issue: [rust-lang/rust#50412](https://github.com/rust-lang/rust/issues/50412)

# Summary
[summary]: #summary

[RFC 243]: https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md#choice-of-keywords

[RFC 243] left the choice of keyword for `catch { .. }` expressions unresolved.
This RFC settles the choice of keyword. Namely, it:

1. reserves `try` as a keyword in edition 2018.
2. replaces `do catch { .. }` with `try { .. }`
3. does **not** reserve `catch` as a keyword.

# Motivation
[motivation]: #motivation

[catch_rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md

[catch_rfc_motivation]: https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md#catch-expressions

This RFC does not motivate `catch { .. }` or `try { .. }` expressions.
To read the motivation for that, please consult [the original `catch` RFC][catch_rfc_motivation].

## For reserving a keyword

Whatever keyword is chosen, it can't be contextual.

As with `catch { .. }`, the syntactic form `<word> { .. }` where `<word>`
is replaced with any possible keyword would conflict with a struct named
`<word>` as seen in this perfectly legal snippet in Rust 2015,
where `<word>` has been substituted for `try`:

```rust
struct try;
fn main() {
    try {
    };
}
```

### Aside note:

The snippet above emits the following warning:

```
warning: type `try` should have a camel case name such as `Try`
```

which is also the case for `catch`.
This warning decreases the risk that someone has defined a type named `try`
anywhere in the ecosystem which happens to be beneficial to us.

## For reserving `try` specifically

This is discussed in the [rationale for `try`][rationale for try].

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

The keyword `try` will be reserved.
This will allow you to write expressions such as:

```rust
try {
    let x = foo?;
    let y = bar?;
    // Note: OK-wrapping is assumed here, but it is not the goal of this RFC
    // to decide either in favor or against OK-wrapping.
    x + y
}
```

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

[list of keywords]: https://doc.rust-lang.org/book/second-edition/appendix-01-keywords.html#keywords-currently-in-use

The word `try` is reserved as a keyword in the [list of keywords]
in Rust edition 2018 and later editions.

The keyword `try` is used in "try expressions" of the form `try { .. }`.

# Drawbacks
[drawbacks]: #drawbacks

There are two main drawbacks to the `try` keyword.

## Association with exception handling - Both a pro and con

> I think that there is a belief – one that I have shared from time to time – that it is not helpful to use familiar keywords unless the semantics are a perfect match, the concern being that they will setup an intuition that will lead people astray. I think that is a danger, but it works both ways: those intuitions also help people to understand, particularly in the early days. So it’s a question of “how far along will you get before the differences start to matter” and “how damaging is it if you misunderstand for a while”.
>
> [..]
>
> Rust has a lot of concepts to learn. If we are going to succeed, it’s essential that people can learn them a bit at a time, and that we not throw everything at you at once. I think we should always be on the lookout for places where we can build on intuitions from other languages; it doesn’t have to be a 100% match to be useful.

\- [Niko Matsakis](https://internals.rust-lang.org/t/bikeshed-rename-catch-blocks-to-fallible-blocks/7121/4)

For some people, the association to `try { .. } catch { .. }` in languages such
as Java, and others in the [prior-art] section, is unhelpful wrt. teachability
because they see the explicit, reified, and manually propagated exceptions in
Rust as something very different than the much more implicit exception handling
stories in Java et al.

[`ExceptT`]: https://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Monad-Except.html#t:ExceptT

However, we make the case that other languages which do have these explicit and
reified exceptions as in Rust also use an exception vocabulary.
Notably, Haskell calls the monad-transformer for adding exceptions [`ExceptT`].

We also argue that even tho we are propagating exceptions manually,
we are following tradition in that other languages have very different
formulations of the exception idea.

The benefit of familiarity, even if not a perfect match, as Niko puts it,
helps in learning, particularly because Rust is not a language in lack of
concepts to learn.

[`try!`]: https://doc.rust-lang.org/nightly/std/macro.try.html

## Breakage of the [`try!`] macro

One possible result of introducing `try` as a keyword be that the old `try!`
macro would break. This could potentially be avoided but with great technical
challenges.

With the prospect of breaking [`try!`], a few notes are in order:

1. `?` was stabilized in 1.13, November 2016, which is roughly 1.4 years since
   the date this RFC was started.
2. `try!` has been "deprecated" since then since:
   > The `?` operator was added to replace `try!` and should be used instead.
3. `try!(expr)` can in virtually all instances be automatically `rustfix`ed
   automatically to `expr?`.
4. There are very few questions on Stack Overflow that mention `try!`.
5. ["The Rust Programming Language", 2nd edition](https://doc.rust-lang.org/book/second-edition/) (book) and "Rust by Example"
   have both already removed all mentions of `try!`.

> So overall I think it’s feasible to reduce the `try!` macro to a historical curiosity to the point it won’t be actively confusing to newbies coming to Rust.

\- [kornel](https://internals.rust-lang.org/t/bikeshed-rename-catch-blocks-to-fallible-blocks/7121/49)

However,

1. There are still plenty of materials out there which mention `try!`.
2. `try!` is essentially the inverse of `try { .. }`.

> Purging from the “collective memories of Rustaceans and Rust materials” is not something that easy.

\- [Manish Goregaokar](https://internals.rust-lang.org/t/bikeshed-rename-catch-blocks-to-fallible-blocks/7121/50)

In the RFC author's opinion however, the sum total benefits of `try { .. }`
seem to outweigh the drawbacks of the difficulty with purging [`try!`] from
our collective memory.

## Inverse semantics of `?`

The `?` postfix operator is sometimes referred to as the "try operator",
and can be seen as having the inverse semantics as `try { .. }`.

To many, this is a drawback. To others, this makes the `?` and `try { .. }`
expression forms more closely related and therefore makes them more findable
in relation to each other.

There is currently some ongoing debate about renaming the `?` operator to
something other than the "try operator". This could help in mitigating the
effects of picking `try` as the keyword.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

## Review considerations

Among the considerations when picking a keyword are, ordered by importance:

1. Fidelity to the construct's actual behavior.

2. Precedent from existing languages
    1. Popularity of the languages.
    2. Fidelity to behavior in those languages.
    3. Familiarity with respect to their analogous constructs.

   See the [prior art][prior-art] the [rationale for try]
   for more discussion on precedent.

2. Brevity.

[`Try`]: https://doc.rust-lang.org/nightly/std/ops/trait.Try.html

4. Consistency with related standard library function conventions.

5. Consistency with the naming of the trait used for `?` (the [`Try`] trait).
   Since the `Try` trait is unstable and the naming of the `?` operator in
   communication is still unsettled, this is not regarded as very important.

6. Degree / Risk of breakage.

7. Consistency with old learning material.

    1. Inversely: The extent of the old learning material

   That is, (in)consistency with `?` and the `try!()` macro.
   If the first clause is called `try`,
   then `try { }` and `try!()` would have essentially inverse meanings.

## Rationale for `try`
[rationale for try]: #rationale-for-try

1. **Fidelity to the construct's actual behavior:** Very high
2. **Precedent from existing languages:** A lot, see [prior-art]
    1. **Popularity of the languages:** Massive accumulated dominance
    2. **Fidelity to behavior in those languages:** Very high
    3. **Familiarity with respect to their analogous constructs:** Very high
3. **Brevity / Length:** 3
4. **Consistency with related libstd fn conventions:** Consistent
5. **Consistency with the naming of the trait used for `?`:** Consistent
6. **Risk of breakage:** High (if we assume `try!` will break, otherwise: Low)
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=try), `std::try!`, but it is technically possible to not break this macro. (unstable: `std::intrinsics::try` so irrelevant)
    - **Used as crate?** [*Yes*](https://crates.io/crates/try). No reverse dependencies. Described as: *"Deprecation warning resistant try macro"*
    - **Usage (sourcegraph):** **27** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+try\s+=|(fn|impl|mod|struct|enum|union|trait)\s+try)\b
    ```
7. **Consistency with old learning material:** Inconsistent ([`try!`])

### Review

This is our choice of keyword, because it:

1. has a massive dominance in both popular and less known languages and is
   sufficiently semantically faithful to what `try` means in those languages.
   Thus, we can leverage people's intuitions and not spend too much of our
   complexity budget.
2. is consistent with the standard library wrt. `Try` and `try_` prefixed methods.
3. it is brief. 
4. it has high fidelity wrt. the concepts it attempts to communicate
   (exception boundary for `?`). This high fidelity is from the perspective of
   a programmers intent, i.e: "I want to try a bunch of stuff in this block".
5. it can be further extended with `catch { .. }` handlers if we wish.

## Alternative: reserving `catch`

1. **Fidelity to the construct's actual behavior:** High
2. **Precedent from existing languages:** Erlang and Tcl, see [prior-art]
3. **Brevity / Length:** 6
4. **Consistency with related libstd fn conventions:** Somewhat consistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=catch)
    - **Used as crate?** [*No*](https://crates.io/crates/catch).
    - **Usage (sourcegraph):** **21** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+catch\s+=|(fn|impl|mod|struct|enum|union|trait)\s+catch)\b
    ```
7. **Consistency with old learning material:** Untaught

### Review

We believe `catch` to be a poor choice of keyword, because it:

1. is used in few in other languages to demarcate the body which can result in
   an exceptional path. Instead, it is almost exclusively used for exception
   handlers of the form: `catch(pat) { recover_expr }`.
4. extending `catch` with handlers will require a different word such as
   `handler` to get `catch { .. } handler(e) { .. }` semantics if we want.
   This inversion compared to a lot of other languages will only harm
   teachability of the language and steal a lot of our strangeness budget.
2. it is less brief than `try`.
3. the consistency wrt. methods in the standard library is low -
   there's only `catch_unwind`, but that has to do with panics,
   not `Try` style exceptions.

However, `catch` has high fidelity wrt. the operational semantics of "catching"
any exceptions in the `try { .. }` block.

## Alternative: keeping `do catch { .. }`

1. **Fidelity to the construct's actual behavior:** Middle
2. **Precedent from existing languages:**
    + `do`: Haskell, Idris
    + `catch`: Erlang and Tcl, see [prior-art]
3. **Brevity / Length:** 8
4. **Consistency with related libstd fn conventions:** Tiny bit consistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Impossible (already reserved keyword)
    - **Used in std:** *No*, the form `$ident $ident` is not a legal identifier.
    - **Used as crate?** *No*, as above.
    - **Usage (sourcegraph):** **0** regex: N/A
7. **Consistency with old learning material:** Untaught

An alternative would be to simply use the `do catch { ... }` syntax we have
in the nightly compiler. However, this syntax was not in the accepted `catch`
RFC and was only a temporary fix around `catch { .. }` not working.

## Alternative: `do try { .. }`

1. **Fidelity to the construct's actual behavior:** High
2. **Precedent from existing languages:**
    + `do`: Haskell, Idris
    + `try`: A lot, see [prior-art]
    1. **Popularity of the languages:** Massive accumulated dominance
    2. **Fidelity to behavior in those languages:** High
    3. **Familiarity with respect to their analogous constructs:** High
3. **Brevity / Length:** 6 (including space)
4. **Consistency with related libstd fn conventions:** Moderately consistent
5. **Consistency with the naming of the trait used for `?`:** Moderately consistent
6. **Risk of breakage:** Impossible (already reserved keyword)
    - **Used in std:** *No*, the form `$ident $ident` is not a legal identifier.
    - **Used as crate?** *No*, as above.
    - **Usage (sourcegraph):** **0** regex: N/A
7. **Consistency with old learning material:** Untaught

### Review

We could in fact decide to keep the `do`-prefix but change the suffix to `try`.
The benefit here would be two-fold:

+ No keyword `try` would need to be introduced as `do` already is a keyword.
  Therefore, the `try!` macro would not break.

+ An association with monads due to `do`. This can be considered a benfit since
  `try` can be seen as sugar for the family of error monads
  (modulo kinks wrt. imperative flow), and thus,
  the `do` prefix leads to a path of generality if more monads are introduced.

The drawbacks would be:

+ The wider association with monads can be seen as a drawback for those not
  familiar with monads.

+ `do try { .. }` over `try { .. }` adds a small degree of ergonomics overhead
  but not much (3 characters including the space). However, the frequency with
  which the `try { .. }` construct might be used can make the small overhead
  accumulate to a significant overhead when a large codebase is considered.

Other than this, the argument for `do try` over `do catch` boils down to an
argument of `try` over `catch`.

## Alternative: using `do { .. }`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** Haskell, Idris
    1. **Popularity of the languages:** Haskell: Tiobe #42, PYPL #22
    2. **Fidelity to behavior in those languages:** Good
    3. **Familiarity with respect to their analogous constructs:** Poor
3. **Brevity / Length:** 2
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Impossible (already reserved keyword)
7. **Consistency with old learning material:** Untaught

### Review

The keyword `do` was probably originally reserved for two use cases:

1. `do while { .. }`

2. Monadic `do`-notation a la Haskell:

   ```haskell
   stuff = do
       x <- actionX
       y <- actionY x
       z <- actionZ
       sideEffect
       finalAction x y z
   ```

   The which would be translated into the following pseudo-Rust:

   ```rust
   let stuff = do {
       x <- actionX;
       y <- actionY(x);
       z <- actionZ;
       sideEffect;
       finalAction(x, y, z);
   };
   ```

   Or particularly for the `try { .. }` case:

   ```rust
   let stuff = try {
       let x = actionX?;
       let y = actionY(x)?;
       let z = actionZ?;
       sideEffect?;
       finalAction(x, y, z)
   };
   ```

   The Haskell version is syntactic sugar for:

   ```haskell
   stuff =  actionX   >>=
      \x -> actionY x >>=
      \y -> actionZ   >>=
      \z -> sideEffect >>
      finalAction x y z
   ```

   or in Rust:

   ```rust
   let stuff =
       actionX.flat_map(|x| // or .and_then(..)
           actionY(x).flat_map(|y|
               actionZ.flat_map(|z|
                   sideEffect.flat_map(|_|
                       finalAction(x, y, z)
                   )
               )
           )
       );
   ```

   In the Haskell version, `>>=` is defined in the `Monad` typeclass (trait):

   ```haskell
   {-# LANGUAGE KindSignatures #-}

   class Applicative m => Monad (m :: * -> *) where
       return :: a -> m a
       (>>=)  :: m a -> (a -> m b) -> m b

       (>>)   :: m a -> m b -> m b
       (>>) = \ma mb -> ma >>= \_ -> mb
   ```

   And some instances (impls) of `Monad` are:

   ```haskell
   -- | Same as Option<T>
   data Maybe a = Nothing | Just a

   instance Monad Maybe where
       return = Just
       (Just a) >>= f = f a
       _        >>= _ = Nothing

   -- | `struct Norm<T> { value: T, normalized: bool }`
   data Norm a = Norm a Bool

   instance Monad Norm where
       return a = Norm a False
       (Norm a u) >>= f = let Norm b w = f a in  Norm b (u || w)
   ```

[`MonadError`]: http://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Monad-Error-Class.html#t:MonadError

Considering the latter case of do-notation,
we saw how `try { .. }` and `do { .. }` relate.
In fact, `try { .. }` is special to the [`Try`] ([`MonadError`]) monads.
There are also more forms of monads which you might want to use `do { .. }` for.
Among these are: Futures, Iterators
Due to having more monads than [`Try`]-based ones,
using the `do { .. }` syntax directly as a replacement for `try { .. }` becomes
problematic as it:

1. confuses everyone familiar with do-notation and monads.
2. is in the way of use for monads in general.
3. `do` is generic and unclear wrt. semantics.

## Alternative: reserving `trap`

1. **Fidelity to the construct's actual behavior:** Good
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 4
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=trap)
    - **Used as crate?** [*No*](https://crates.io/crates/trap).
    - **Usage (sourcegraph):** **4** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+trap\s+=|(fn|impl|mod|struct|enum|union|trait)\s+trap)\b
    ```
7. **Consistency with old learning material:** Untaught

### Review

Arguably, this candidate keyword is a somewhat a good choice.

To `trap` an error is sufficiently clear on the "exception boundary" semantics
we wish to communicate.

However, `trap` is used as an error handler in at least one language.

It also does not have the familiarity that `try` does have and is entirely
inconsistent wrt. naming in the standard library.

## Alternative: reserving `wrap`

1. **Fidelity to the construct's actual behavior:** Somewhat good
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 4
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=wrap)
    - **Used as crate?** [*Yes*](https://crates.io/crates/wrap), no reverse dependencies.
    - **Usage (sourcegraph):** **37+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+wrap\s+=|(fn|impl|mod|struct|enum|union|trait)\s+wrap)\b
    ```
7. **Consistency with old learning material:** Untaught

### Review

With `wrap { .. }` we can say that it "wraps" the result of the block as a
`Result` / `Option`, etc. and it is logically related to `.unwrap()`,
which is however a partial function, wherefore the connotation might be bad.

Also, `wrap` could be considered too generic as with `do` in that it could
fit for any monad.

## Alternative: reserving `result`

1. **Fidelity to the construct's actual behavior:** Somewhat good
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 6
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very high
    - **Used in std:** [*Yes*](https://doc.rust-lang.org/nightly/std/?search=result) for the `{std, core}::result` modules.
    - **Used as crate?** [*Yes*](https://crates.io/crates/result). 6 reverse dependencies (transitive closure).
    - **Usage (sourcegraph):** **43+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+result\s+=|(fn|impl|mod|struct|enum|union|trait)\s+result)\b
    ```
7. **Consistency with old learning material:** Untaught

## Review

[final encoding]: http://okmij.org/ftp/tagless-final/course/lecture.pdf

The fidelity of `result` is somewhat good due to the association with the
`Result` type as well as `Try` being a [final encoding] of `Result`.

However, when you consider `Option`, the association is less direct,
and thus it does not fit `Option` and other types well.

The breakage of the `result` module is however quite problematic,
making this particular choice of keyword more or less a non-starter.

## Alternative: a smattering of other possible keywords

There are a host of other keywords which have been suggested.

### `fallible`

On an [internals thread](https://internals.rust-lang.org/t/bikeshed-rename-catch-blocks-to-fallible-blocks/7121/), `fallible` was suggested. However, this keyword lacks the verb-form that
is the convention in Rust. Breaking with this convention should only be done
if there are significant reasons to do so, which do not seem to exist in this
case. It is also considerably longer than `try` (+5 character) which matters
for constructions which are oft used.

1. **Fidelity to the construct's actual behavior:**  High
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 8
4. **Consistency with related libstd fn conventions:** Highly inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=fallible)
    - **Used as crate?** [*Yes*](https://crates.io/crates/fallible), some reverse dependencies (all by the same author).
    - **Usage (sourcegraph)** [*None*](https://sourcegraph.com/search?q=repogroup:crates+case:yes++%5Cb%28%28let%7Cconst%7Ctype%7C%29%5Cs%2Bfallible%5Cs%2B%3D%7C%28fn%7Cimpl%7Cmod%7Cstruct%7Cenum%7Cunion%7Ctrait%29%5Cs%2Bfallible%29%5Cb+max:400)
7. **Consistency with old learning material:** Untaught

### Synonyms of `catch`:

Some synonyms of `catch` [have been suggested](https://internals.rust-lang.org/t/bikeshed-rename-catch-blocks-to-fallible-blocks/7121/2):

#### `accept`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 6
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Medium
    - **Used in std:** [*Yes*](https://doc.rust-lang.org/nightly/std/?search=accept)
    - **Used as crate?** [*No*](https://crates.io/crates/accept).
    - **Usage (sourcegraph):** **79+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+accept\s+=|(fn|impl|mod|struct|enum|union|trait)\s+accept)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `capture`

1. **Fidelity to the construct's actual behavior:** Good.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 7
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=capture)
    - **Used as crate?** [*Yes*](https://crates.io/crates/capture), no reverse dependencies.
    - **Usage (sourcegraph):** **6+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+capture\s+=|(fn|impl|mod|struct|enum|union|trait)\s+capture)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `collect`

1. **Fidelity to the construct's actual behavior:** Very much not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 7
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very high
    - **Used in std:** [*Yes*](https://doc.rust-lang.org/nightly/std/?search=collect) (`Iterator::collect`)
    - **Used as crate?** [*Yes*](https://crates.io/crates/collect), no reverse dependencies.
    - **Usage (sourcegraph):** **35+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+collect\s+=|(fn|impl|mod|struct|enum|union|trait)\s+collect)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `recover`

1. **Fidelity to the construct's actual behavior:** Good
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 7
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=recover)
    - **Used as crate?** [*No*](https://crates.io/crates/recover)
    - **Usage (sourcegraph):** **4+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+recover\s+=|(fn|impl|mod|struct|enum|union|trait)\s+recover)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `resolve`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 7
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Low to medium
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=resolve)
    - **Used as crate?** [*Yes*](https://crates.io/crates/resolve), 3 reverse dependencies
    - **Usage (sourcegraph):** **50+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+resolve\s+=|(fn|impl|mod|struct|enum|union|trait)\s+resolve)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `take`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 4
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Huge
    - **Used in std:** [*Yes*](https://doc.rust-lang.org/nightly/std/?search=take), `{Cell, HashSet, Read, Iterator, Option}::take`.
    - **Used as crate?** [*Yes*](https://crates.io/crates/resolve), a lot of reverse dependency (transitive closure).
    - **Usage (sourcegraph):** **62+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+take\s+=|(fn|impl|mod|struct|enum|union|trait)\s+take)\b
    ```
7. **Consistency with old learning material:** Untaught

#### Review

Of these, only `recover` and `capture` seem reasonable semantically.
But `recover` is even more problematic than `catch` because it enhances
the feeling of exception-handling instead of exception-boundaries.
However, `capture` is reasonable as a substitute for `try`,
but it seems obscure and lacks familiarity, which is counted as a strong downside.

### [and some other keywords:](https://internals.rust-lang.org/t/bikeshed-rename-catch-blocks-to-fallible-blocks/7121/13)

#### `coalesce`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 8
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Medium (itertools)
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=coalesce).
    - **Used as crate?** [*Yes*](https://crates.io/crates/coalesce), one reverse dependency.
    - **Usage (sourcegraph):** **3+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+coalesce\s+=|(fn|impl|mod|struct|enum|union|trait)\s+coalesce)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `fuse`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 4
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Medium (libstd)
    - **Used in std:** [*Yes*](https://doc.rust-lang.org/nightly/std/?search=fuse), `Iterator::fuse`.
    - **Used as crate?** [*Yes*](https://crates.io/crates/fuse), 8 reverse dependencies (transitive closure).
    - **Usage (sourcegraph):** **8+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+fuse\s+=|(fn|impl|mod|struct|enum|union|trait)\s+fuse)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `unite`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 5
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=unite).
    - **Used as crate?** [*No*](https://crates.io/crates/unite).
    - **Usage (sourcegraph):** **0+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+unite\s+=|(fn|impl|mod|struct|enum|union|trait)\s+unite)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `cohere`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 6
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=cohere).
    - **Used as crate?** [*No*](https://crates.io/crates/cohere).
    - **Usage (sourcegraph):** **0+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+cohere\s+=|(fn|impl|mod|struct|enum|union|trait)\s+cohere)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `consolidate`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 11
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=consolidate).
    - **Used as crate?** [*No*](https://crates.io/crates/consolidate).
    - **Usage (sourcegraph):** **0+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+consolidate\s+=|(fn|impl|mod|struct|enum|union|trait)\s+consolidate)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `unify`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 5
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=unify).
    - **Used as crate?** [*Yes*](https://crates.io/crates/unify), no dependencies
    - **Usage (sourcegraph):** **1** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+take\s+=|(fn|impl|mod|struct|enum|union|trait)\s+take)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `combine`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 7
4. **Consistency with related libstd fn conventions:** Inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Medium
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=combine).
    - **Used as crate?** [*Yes*](https://crates.io/crates/combine), 17 (direct dependencies)
    - **Usage (sourcegraph):** **6+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+combine\s+=|(fn|impl|mod|struct|enum|union|trait)\s+combine)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `resultof`

1. **Fidelity to the construct's actual behavior:** Somewhat
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 8
4. **Consistency with related libstd fn conventions:** Very inconsistent (not verb)
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:** Very low
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=resultof).
    - **Used as crate?** [*No*](https://crates.io/crates/resultof).
    - **Usage (sourcegraph):** **0+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+resultof\s+=|(fn|impl|mod|struct|enum|union|trait)\s+resultof)\b
    ```
7. **Consistency with old learning material:** Untaught

#### `returned`

1. **Fidelity to the construct's actual behavior:**  Not at all.
2. **Precedent from existing languages:** None
3. **Brevity / Length:** 8
4. **Consistency with related libstd fn conventions:** Very inconsistent
5. **Consistency with the naming of the trait used for `?`:** Inconsistent
6. **Risk of breakage:**
    - **Used in std:** [*No*](https://doc.rust-lang.org/nightly/std/?search=returned).
    - **Used as crate?** [*No*](https://crates.io/crates/returned).
    - **Usage (sourcegraph):** **0+** regex:
    ```
    repogroup:crates case:yes max:400
    \b((let|const|type|)\s+returned\s+=|(fn|impl|mod|struct|enum|union|trait)\s+returned)\b
    ```
7. **Consistency with old learning material:** Untaught

#### Review

Of these, only `resultof` seems to be semantically descriptive and has some support. However, it has three major drawbacks:

+ Length: Compared to `try`, it is 5 characters longer (see reasoning for `fallible`).

+ Not a word: `resultof` is in fact a concatenation of `result` and `of`.
  This does not feel like a natural fit for Rust, as we tend to use a `_` separator.
  Furthermore, there are no current keywords in use that are concatenations of two word.

+ `Result<T, E>` oriented: `resultof` is too tied to `Result<T, E>` and fits poorly with `Option<T>` or other types that implement `Try`.

# Prior art
[prior-art]: #prior-art

All of the languages listed below have a `try { .. } <handler_kw> { .. }` concept
(modulo layout syntax / braces) where `<handler_kw>` is one of:
`catch`, `with`, `except`, `trap`, `rescue`.

In total, these are 29 languages and they have massive ~80% dominance according
to the [TIOBE index](https://www.tiobe.com/tiobe-index/)
and roughly the same with the [PYPL index](http://pypl.github.io/PYPL.html).

+ [C++](http://en.cppreference.com/w/cpp/language/try_catch)
+ [D](https://tour.dlang.org/tour/en/basics/exceptions)
+ [C#](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch)
+ [Java](https://docs.oracle.com/javase/tutorial/essential/exceptions/try.html)
+ [Scala](https://stackoverflow.com/questions/18685573/try-catch-finally-return-value)
+ [Kotlin](https://kotlinlang.org/docs/reference/exceptions.html)
+ [JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch)
+ [TypeScript](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-5.html)
+ [ActionScript](https://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7ed1.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7ec5)
+ [Dart](https://www.dartlang.org/resources/dart-tips/dart-tips-ep-9)
+ [Python](https://docs.python.org/3/tutorial/errors.html)
+ [PHP](http://php.net/manual/en/language.exceptions.php)
+ [Matlab](https://se.mathworks.com/help/matlab/ref/try.html)
+ [Visual Basic](https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/statements/try-catch-finally-statement)
+ [OCaml](https://ocaml.org/learn/tutorials/error_handling.html)
+ [F#](https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/exception-handling/the-try-with-expression)
+ [Objective C](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ErrorHandling/ErrorHandling.html#//apple_ref/doc/uid/TP40011210-CH9-SW3)
+ [Swift](https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html)
+ [Delphi](https://stackoverflow.com/questions/6601147/how-to-correctly-write-try-finally-except-statements)
+ [Julia](https://docs.julialang.org/en/stable/manual/control-flow/#The-try/catch-statement-1)
+ [Elixir](https://elixir-lang.org/getting-started/try-catch-and-rescue.html)
+ [Erlang](http://erlang.org/doc/reference_manual/expressions.html#try)
+ [Clojure](https://clojuredocs.org/clojure.core/try)
+ [R](https://www.rdocumentation.org/packages/base/versions/3.0.3/topics/conditions), modulo minor syntactic difference.
+ [Powershell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_try_catch_finally?view=powershell-6)
+ [Tcl](http://wiki.tcl.tk/8293)
+ [Apex](https://developer.salesforce.com/page/An_Introduction_to_Exception_Handling)
+ [RPG](http://devnet.asna.com/documentation/Help102/AVR/_HTML/TRYCATCHFINALLY.htm)
+ [ABAP](https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abaptry.htm)

The syntactic form `catch { .. }` seems quite rare and is,
together with `trap`, `rescue`, `except`, only used for handlers.
However, the `<kw> { .. }` expression we want to introduce is not a handler,
but rather the body of expression we wish to `try`.

There are however a few languages where `catch { .. }` is used for the fallible
part and not for the handler, these languages are:
+ [Erlang](http://erlang.org/doc/reference_manual/expressions.html#catch)
+ [Tcl](https://www.tcl.tk/man/tcl/TclCmd/catch.htm)

However, the combined popularity of these languages are not significant as
compared to that for `try { .. }`.

# Unresolved questions
[unresolved]: #unresolved-questions

None as of yet.
