Pre-RFC: Catching Functions

language design
69

My concerns with this proposal are like my concerns with the other Ok-wrapping proposals: this hurts learnability of the language, because you make something that was previously simply a more or less “normal” type, Result, even more special than it is right now. The ? operator is of the same kind, and its addition was problematic for the same reason. Also, like the other Ok proposals, this proposal is mostly a collection of syntactic sugar that isn’t even that sweet. This is less because the proposal is bad, more because there isn’t much “sweetness” to add.

The biggest advantage I see from adopting this proposal is that unlike try!(Err(expr)) throw expr evaluates to the never type in expression context, which allows for nicer code in some places. E.g. allowing code like:

let f = match something() {
    CoolEnum::Variant(v) => v,
    _ => throw LibError::OhNo,
}

The alternative that works now would be return Err(...) but I’m no big fan of it.

So overall I’m not a great fan of this proposal.

However, I think that this proposal is better than the RFCs proposed during the impl period. Especially I like the fact that this syntax is specifically opt-in instead of relying on the type checker and only performing the wrapping if the expression of the returned type is not a Result.

4 Likes