You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have an (extremely) contrived example below where I care about the error result coming from my_function, but the clippy suggestion (ok().map_or_else()) would hide the error result, and the suggestion in the clippy output doesn't compile! (See the bottom of this post.)
The real example is transforming multiple kinds of errors, such as missing fields, malformed data, or error results from other crates, and I'm interested in why this function fails. In my case, the readability is much less important than getting the details from the error.
If it makes a difference, the real example is transforming a Result into a FutureResult, and the success path makes additional calls which returns Futures. My function returns a Future with Either::A() as the success result and Either::B() as the failure result, so I want to preserve the error information.
I think my particular problem would be better served with result.map_or_else(), but that's not available on the stable channel. I also think that result.map_or_else(), if and when it becomes stable, would be a better suggestion for clippy to make in this case.
I disagree with the sentiment behind the result_map_unwrap_or_else lint. As a consequence, I'm allowing this lint for my current crate. If this is the preferred way of handling this, then please just close the issue.
This lint is bad because it's suggestion isn't equivalent to the code it wants to replace. I think it should be moved to nursery until result.map_or_else stabilizes.
This was discussed in parallel in the original lint's issue, and was fixed by #4848 changing the lint suggestion in line with Result::map_or_else being stabilized.
cargo clippy -V
clippy 0.0.212 (2e26fdc 2018-11-22)
In regards to result_map_unwrap_or_else
I have an (extremely) contrived example below where I care about the error result coming from
my_function
, but the clippy suggestion (ok().map_or_else()
) would hide the error result, and the suggestion in the clippy output doesn't compile! (See the bottom of this post.)The real example is transforming multiple kinds of errors, such as missing fields, malformed data, or error results from other crates, and I'm interested in why this function fails. In my case, the readability is much less important than getting the details from the error.
If it makes a difference, the real example is transforming a Result into a FutureResult, and the success path makes additional calls which returns Futures. My function returns a Future with Either::A() as the success result and Either::B() as the failure result, so I want to preserve the error information.
I think my particular problem would be better served with
result.map_or_else()
, but that's not available on the stable channel. I also think thatresult.map_or_else()
, if and when it becomes stable, would be a better suggestion for clippy to make in this case.I disagree with the sentiment behind the
result_map_unwrap_or_else
lint. As a consequence, I'm allowing this lint for my current crate. If this is the preferred way of handling this, then please just close the issue.EXAMPLE:
Output from cargo run:
Output from clippy:
clippy's suggestion actually doesn't compile:
The text was updated successfully, but these errors were encountered: