My biggest complaint with it is that it means return Some(4) and return None do drastically-different things in a function that's -> Option<Option<i32>>.
See rfcs/text/0000-ok-wrapping.md at ok-wrapping · scottmcm/rfcs · GitHub for more.
(And there definitely shouldn't be a From::from in there, since that keeps things like return 4; from working normally.)
But is that function-level catch or a catch expression? It matters if there's a return in the closure.
It needs to be a bit magic, though, so code is more similar between fallible and infallible functions.
I think counting characters is absolutely the wrong measurement here. The big advantage I want out of this is that it becomes normal to always type the ? after something you know can fail as the first pass, allowing the first pass at the method to be written just like it was infallible.
Reminds me of this paper...
https://www.microsoft.com/en-us/research/publication/exceptional-syntax/
I think this is partially due to a lack of keyword highlighting. Changing a letter to get the highlighting helps it stand out.
fn foo<F: Fn(&File) -> bool>(&mut self, f: F) -> Result<i32, io::Error> {
fn foo<F: Fn(&File) -> bool>(&mut self, f: F) -> match Result<i32, io::Error> {
fn foo<F: Fn(&File) -> bool>(&mut self, f: F) -> i32 match io::Error {
And one thing I like about having the type there is that it allows aliases, as are common today:
fn foo<F: Fn(&File) -> bool>(&mut self, f: F) -> match io::Result<i32> {
// no `Error` anywhere
(To be super-explicit just in case: I'm definitely not suggesting match as the keyword 
)