True, and it's been discussed for a reason. Do you enjoy having to type Ok(()) all over the place whenever your function has to do a lot of error checking? I highly doubt it.
For some pattern matching is nothing but a convenience feature - we could all use the standard "switch" operator the way good old fashioned C does, couldn't we? Yet Rust is loved, in part, thanks to the features, some of which were added purely for convenience. The "if let"s , the "Try"s are not there because it's impossible to work without them - they are there because it makes sense.
Your argument is the same as the one tackled by the author of fehler:
The error path should not be invisible
This is the most common counterargument and it is very easy to respond to: I agree that the error path should not be invisible. That’s why I’ve never advocated making any change to how the error path is handled. It is still necessary to use ? to “rethrow” an exception.
And yet it’s always one of the first and most popular comments any time this discussion is brought up again. I wish people would put a bit more effort in understanding things before making comments on them, but all evidence suggests this is not the natural behavior of humans on the internet.
Let me just repeat: no one is proposing to make the error path invisible. If you think that is the consequence of throwing/catching function proposals, you have misunderstood these proposals and you should start again.
I actually find this complaint quite ironic, because ok-wrapping syntax would make it easier to identify all of the error paths because of the way it interacts with implicit final return. Today, when a function call returning a result ends in an implicit return, if that function is also returning a result, it is totally unmarked. But this syntax would require, even in that case, that that terminal function call be annotated with ?, identifying it as fallible. With this syntax, now every fallible path is marked with ? or a throw expression. This is more consistent and more explicit!
To avoid strawman'ing your point, I can say that I do understand where you're coming from - silent errors are the worst. However, whenever you declare an
fn with arguments and no return type, which ends with a statement, you're silently dropping an explicit
() which might be useful for someone to understand that the function has officially finished its work. But we don't do that - because it's not that important, is it? It takes a special kind of negligence to go through 5 to 10 tries of ? only to let the function silently proceed up to wrapping a non-result
() in an
Ok only to discover the error later. The same kind of negligence it would take to cause dead-locks with mutexes - but that's bairly a reason to avoid using them, or to retype 4 parenthesis near the Ok over and over.
Ok is definitely important - when there's something to see. Any
Result is an enum - which either succeeds or it doesn't. And if there's no success value to provide back to the stack, it makes no sense to be repetitively explicit about the fact that the function is done, but there's nothing to return.
Once again, if it would just my own pet peeve, I wouldn't mind - but there are quite a few people for whom it's not only not a fun exercise, but a completely meaningless one at that.