M-IMPL-ASREF: clarify additional constraints on where to apply this rule

[martintmk]

Applying this rule broadly can introduce a lot of generics into the code and therefore increase the compile times. Shouldn't this rule clarify that impl AsRef is preferrable on public APIs only? I think for internal helpers is perfectly fine to accept &str rather than impl AsRef<str>.

I have also tried to run AI agent to apply this rule to my codebase and it was overly zealous. For example it tried to replace:

pub struct MyObject;
pub fn process(obj: &MyObject) { ... }

with:

pub struct MyObject;
pub fn process(obj: impl AsRef<MyObject>) { ... }

Where this would not even compile as MyObject does not implement AsRef. I think this should be clarified so if there is no naive conversion from AsRef, the rule should not apply.

[ralfbiedert]

Yes you are right, it's for public APIs.