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.