Mismatch between `?` and final return type

There is a slight difference between the Try operator (?) and just returning a result. This is that the try operator will call Into::into From::from on the error type.

I propose adding a method to Result called something like map_err_into that is implemented with map_err(Into::into) map_err(From::from).

The main reason for adding it would not be ergonomics (the original is already pretty straightforward), but discoverability: it gives us somewhere to write about the difference between ? and return (either implicit or explicit), and to provide guidance along the lines of "if you want your return to work like Try, use this method."

What's wrong with "if you want your return to work like Try, use map_err(Into::into)."?

Hoping that this won't divert your thread into the same rehashed arguments back and forth, this is one of advantages of an ok wrapping syntax: by requiring ? on the final return expression to unwrap a terminal error, we make the implicit return behave consistent with the explicit ? operator, making the experience of error handling more consistent and normalized.

To be emphatic, I would love it if people did not make this thread about the same arguments we know in favor of and against ok wrapping in general but stuck to the specifics of the distinction between ? and the final return type.

3 Likes

It actually uses From::from. I recently tried to make it use Into, but it was horrible for type inference.

2 Likes

I usually just add a conv_err() method in a ResultExt trait and move on. It would be indeed convenient to have the .map_err(From::from) idiom in std. I don't think discussion about implicit Ok-wrapping is relevant or constructive here.

3 Likes