That seems like a trivial, mechanical process that is easily automated using refactoring tools in the IDE (or simply through regex search/replace) and the benefit of that doesn’t seem like a strong argument to the readability of the code. I’m with many others that believe that ultimately, readability and the principle of least surprise when reading code, especially if you routinely work with multiple languages and Rust isn’t your primary PL or you are new to Rust, is the most important thing to consider, not how easy it is to refactor or write in the first place. My argument would be that this whole notion of “try fn/fn” is less “readable/understandable” than your earlier proposed return/pass/fail/bare-expr proposal (without “try fn”) is MUCH, MUCH better for the kind of readability I’m referring to.
To be clear, I understand the goal is:
- How do we auto-wrap consistently so we don’t need to explicitly state Ok(expr) vs Error(expr) vs Some(expr) vs None vs some other thing that implements the Try trait?
Then, I understand that the initial proposal is the “fn vs try fn” with auto-wrapping as you’ve described (though it has been refined in the discussion). But, you (or was it someone else) at some point proposed eliminating “try fn” and using keywords to indicate auto-wrapping: return (no auto-wrap), pass/fail (auto-wrap), bare expr (no auto-wrap).
My contention is that the second proposal with the keywords is superior for readability/understandability and that that is more important for motivating the solution than refactoring/writing ease. I’m sure others (and it seems like you) disagree, but, I think many agree on the writing vs reading and which is more important. If you think about it, you read code others have written (or that you’ve written long ago) more often that you write/re-factor code (once you get into long-term maintenance).