Use ? instead of try! internally and in generated code

[Lucretiel]

Much of serde's implementation uses try!, which I assumed was for backwards compatibility reasons. However, while support for Option was only added in Rust 1.22, the ? itself was added in Rust 1.13, a much earlier version than serde's claimed MSRV of 1.19.

I'd need to bench to be sure, but my presumption is that ?, a built-in operator, is faster for the compiler than expanding the try! macro.

[dtolnay]

The last time I checked (~1 year ago) ? still produced larger binaries than try!, compiled slower, and had worse performance at runtime.

[Lucretiel]

Surprising but fair enough.

[Lucretiel]

Supposedly this was fixed last August: rust-lang/rust#37939

[dtolnay]

Oh nice. I think that issue was only in regard to runtime performance though? I tried to check compile time using this diff in serde_derive:

         macro_rules! try {
             (#dollar __expr:expr) => {
-                match #dollar __expr {
-                    _serde::__private::Ok(__val) => __val,
-                    _serde::__private::Err(__err) => {
-                        return _serde::__private::Err(__err);
-                    }
-                }
+                #dollar __expr?
             }
         }

and using the following commands:

• In https://github.com/serde-rs/json-benchmark:
  • touch src/lib.rs; time CARGO_INCREMENTAL=0 cargo check --no-default-features --features all-files,parse-struct,lib-serde
  • touch src/lib.rs; time CARGO_INCREMENTAL=0 cargo build --release --no-default-features --features all-files,parse-struct,lib-serde
• In https://github.com/gluon-lang/lsp-types:
  • touch src/lib.rs; time CARGO_INCREMENTAL=0 cargo check
  • touch src/lib.rs; time CARGO_INCREMENTAL=0 cargo build

and these all compile consistently 6.5–7.5% slower on my machine with ?, using current nightly. That's the identical ratio noted 5 years ago in #1121 (comment). ? just generates more inference variables, and function calls / copies / layers of trait abstractions that need to get compiled or inlined.

The gap would be larger upon using ? in serde_json too, since that currently uses its own tri! macro, for the same reason.

Maybe the gap would be slightly smaller with try! eliminated entirely from serde_derive in favor of directly using ? throughout all the quote! blocks, but not by more than 0.25% percentage points I'd guess. A tiny macro_rules like that is effectively instant to expand compared to type checking.

I did confirm the json-benchmark produces an identical binary after strip, so that's great. I could believe it no longer makes sense to use try! at this point considering the deleterious effect on readability of cargo expand output.