> The question mark operator is unrelated to async - you might say "fallible functions" instead.
This jumped out at me too and I think it would be better stated as “this function doesn’t handle this error” or “this function may produce this error”, which is basically checked exceptions ~without error handling as arbitrary control flow.
> Not really a class. There isn't a good parallel to this in most other languages.
It’s a lot more like a class than the next most obvious TypeScript idiom (structural type compatibility/duck typing). It has to be explicitly defined and that’s the most important part coming from a JS/TS background.
I agree with and fully endorse the rest of this comment.
> which is basically checked exceptions ~without error handling as arbitrary control flow.
With the `?` operator, Rust behaves identically to a language with checked exceptions as it also has "arbitrary control flow" in that the code may "jump" elsewhere on errors. The implementation may be different, but the abstraction is identical.
The places it may jump are explicitly marked in the code, though. And that makes a tremendous difference in readability. The problem with exceptions is not the alternative control flow, but the fact it is hidden, and an exception can come out of nowhere, from 10 layers below (that's particularly bad for unchecked where you can't see them even in signatures).
I really don’t think it is that much of a problem. You almost always want a high-level error handling logic, and not all errors can or should be handled at callsite. Rust’s ? macro is a good tradeoff, but I really do think that exceptions are the best way of error handling — optionally marking a given exception type as “should be handled” aka checked exceptions. Though existing implementations are not without errors.
I genuinely don’t think this is right! The syntax is equivalent to try->catch->throw or whatever but it doesn’t change the fact that the function has a clear either/Result type. Every call site gets the same return and has the same error semantics whether that syntax is used or an explicit return statement/expression is used. ? just means it’s a potential early return. Not a goto.
This jumped out at me too and I think it would be better stated as “this function doesn’t handle this error” or “this function may produce this error”, which is basically checked exceptions ~without error handling as arbitrary control flow.
> Not really a class. There isn't a good parallel to this in most other languages.
It’s a lot more like a class than the next most obvious TypeScript idiom (structural type compatibility/duck typing). It has to be explicitly defined and that’s the most important part coming from a JS/TS background.
I agree with and fully endorse the rest of this comment.