As someone who was on the fence about it, I feel exactly the same. The way the Rust maintainers and proponents of post-fix await helped create broader community consensus was impressive in itself too.

> It's not any more verbose

Seriously? I think this is way less readable:

  (|| -> Result<_,_> { bar(foo()?) })()

than this:

  try { bar(foo()?)? }

Also try_blocks don't have to have a "catch". It's just five characters: "t" "r" "y" "{" "}". I don't see a need for "catch" either.

That may work for most cases (and is what I myself often do), but it's worth keeping in mind that it won't work in general. There are many situations where closures are not a replacement for imperative blocks, because the compiler has an understanding of exclusive paths in imperative control flow that does not apply to closures. Eg:

    fn foo(cond: bool, s: String) {
        if cond {
            drop(s);
        }
        else {
            drop(s);
        }
    }

... compiles file even though `s` is being consumed in two different locations, because the compiler is aware of the control flow of if-then-else so it knows only one arm can be executed.

If you tried to replace the bodies of the two branches with closures, it would not compile, because both need to consume the String. That is,

    fn if_(cond: bool, t: impl FnOnce(), f: impl FnOnce()) { if cond { t() } else { f() } }

    fn foo(cond: bool, s: String) {
        if_(cond, || drop(s), || drop(s));
    }

... won't compile. Even though only one of the two closures will be executed, both closures need to be created regardless, which means both need to own the String, which is not allowed.

This problem came up all the time in pre-async-await futures 0.1 code because async code had to be written with futures combinators that all used closures, so even in cases where the programmer knows only one closure will be invoked, they would still need to clone their values so that each closure could own them. Even in regular non-async code, it often comes up with the combinators like `Result::map_err`, like:

    enum Error {
        Io { path: PathBuf, inner: std::io::Error },
        Deserialize { path: PathBuf, inner: serde_yaml::Error },
    }

    fn read_config(path: PathBuf) -> Result<Config, Error> {
        let f = std::fs::File::open(&path).map_err(|err| Error::Io { path: path.clone(), inner: err  })?;
        let c = serde_yaml::from_reader(&f).map_err(|err| Error::Deserialize { path, inner: err })?;
        Ok(c)
    }

Notice the `path.clone()` in the first Result's map_err closure, which is needed even though the programmer knows there is nothing else that will use `path` once that statement executes. That's because, once again, both `map_err` closures need to be created regardless of whether they execute or not, so for the second closure to be created it must own `path`, and thus the first closure needs to clone it. The equivalent code with explicit `match` statements for each Result expr would not need to clone. Compare `read_config` and `read_config2` in https://play.rust-lang.org/?version=stable&mode=debug&editio...

They also enable "early exiting" a block, so it's much easier to check for an error in the middle of a block: currently you'd need extra indentation or a `map` / `and_then` (which can lead to the compiler being unhappy as it has more flexibility within a function than across functions). So e.g.

    let result = {
        let a = a_thing();
        let b = another_thing();
        let c = a.foo(b)?;
        if c.a_thing() {
            Ok(c)
        } else {
            Err(…)
        }
    };

which currently has to be written

    let result = {
        let a = a_thing();
        let b = another_thing();
        a.foo(b).and_then(|c|
            if c.a_thing() {
                Ok(c)
            } else {
                Err(…)
            }
        )
    }

which doesn't look too bad for a simple example but can get out of hand if you need multiple thus, and as mentioned above the compiler can start being an issue if you work across-functions a lot.