Suggest using `opt.is_none_or` instead of `!opt.is_some_and`

[antonilol]

What it does

Suggests using opt.is_none_or(...) instead of !opt.is_some_and(...), also suggests to invert the boolean expression inside the closure to keep the two equivalent.

I can imagine some algorithm that will try to invert the expression in the 'nicest' way, converting (just examples)

• a < b to a >= b
• a == b to a != b
• result.is_ok() to result.is_err()
• !(expr) to expr
• Finally, if the above do not work for a specific expression, just put a ! in front of the expression, and parentheses around it if necessary.

If a function pointer is passed in, convert it to a closure and put ! in front of it (|args| !function(args)).

Advantage

• Convert harder to read !(option is some && some expression) to option is none || !(some expression).

Drawbacks

• This can introduce unnecessary closures (see last line of "What it does").

Example

!opt.is_some_and(|x| x >= 1000)

Could be written as:

opt.is_none_or(|x| x < 1000)

[antonilol]

The same can be done for !opt.is_none_or.

Also, Option::is_none_or is stabilized and planned to be included in the 1.82 release, so should not be suggested to be used on version <= 1.81.

[SpriteOvO]

@rustbot claim

[SpriteOvO]

If a function pointer is passed in, convert it to a closure and put ! in front of it (|args| !function(args)).

I think it's best to give up expanding function pointers to closures. First of all this makes the code longer, and the purpose of function pointer passing in is shorter code. Second, if expanding to a closure, we have to name the parameter, but obviously we don't have a way to get a meaningful name, which can only be x or arg.

!opt.is_some_and(blah) -> opt.is_none_or(|x| !blah(x))

IMO, this doesn't make the code more readable.