Suggest Option::is_some_and(...) instead of map_or(false, ...) and similar for Results

[sdroege]

What it does

Given the following code

// 1
if some_option.map_or(false, |x| some_predicate(x)) {
    // do something
}
// 2
if some_option.map(|x| some_predicate(x)).unwrap_or(false) { // unwrap_or_default() etc
    // do something
}
// 3
if some_result.map_or(false, |x| some_predicate(x)) {
    // do something
}
// 4
if some_result.map(|x| some_predicate(x)).unwrap_or(false) { // unwrap_or_default() etc
    // do something
}

it would suggest

// 1
if some_option.is_some_and(|x| some_predicate(x)) {
    // do something
}
// 2
if some_option.is_some_and(|x| some_predicate(x)) {
    // do something
}
// 3
if some_result.is_ok_and(|x| some_predicate(x)) {
    // do something
}
// 4
if some_result.is_ok_and(|x| some_predicate(x)) {
    // do something
}

Not sure if there's something meaningful around Result::is_err_and() that can be transformed in the same way

Advantage

Shorter and more descriptive

Drawbacks

Requires MSRV 1.70

Example

See example in initial description

[y21]

Case 1 and 3 looks like #11848 (which has an implementation PR open). Case 2 and 4 should already be covered by manual_is_variant_and.

[sdroege]

Hrm, did I typo while searching for these. Sorry for the noise!

I don't think these should be pedantic though and could be enabled by default as well.