I'm seeing the or_fun_call lint complain about use of methods that are cheap (e.g. vec.first(), x.as_ref().and_then(…), x.unwrap_or("str"), "".as_ref(), x.unwrap_or(Path::new(""))).
I've searched previous discussions about this lint, and it seems that various heuristics for detecting cheap methods were rejected, because sometimes there are edge cases that might be expensive.
Could there be another lint, or a setting for this lint, that changes the policy from warning just in case to warning only about methods that are actually known to have non-trivial cost? (prefer false negatives over false positives)
Description
I'm seeing the
or_fun_call
lint complain about use of methods that are cheap (e.g.vec.first()
,x.as_ref().and_then(…)
,x.unwrap_or("str")
,"".as_ref()
,x.unwrap_or(Path::new(""))
).I've searched previous discussions about this lint, and it seems that various heuristics for detecting cheap methods were rejected, because sometimes there are edge cases that might be expensive.
Could there be another lint, or a setting for this lint, that changes the policy from warning just in case to warning only about methods that are actually known to have non-trivial cost? (prefer false negatives over false positives)
Version
Additional Labels
No response