Warn for passing Box<&dyn Any> to function taking &dyn std::any::Any

[Wumpf]

What it does

Issue a warning if a function takes any of

• &dyn std::any::Any
• &mut dyn std::any::Any

The recommendation is to either use an existing trait type or create a "marker trait" to specify what the method can actually process in order to avoid passing (by accident) object references of unexpected types.

EDIT: Only warn when Box<&dyn Any> is passed as-is. Recommend box.as_ref()

Advantage

Beside the obvious advantages of a more concrete type, there's major pitfalls with &dyn Any: Since &Box<Any> itself implements Any, it can easily happen that one accidentally passes the box directly instead of the desired box.as_ref(). This can be the cause of quite hard to debug issues.

Drawbacks

While it's more often than not a shortcut for not defining a trait type, there are likely legitimate usecases for passing &dyn Any (examples?)

Example

Updated suggestion:

fn func(value: &dyn std::any::Any) { ... }

func(box);

Could be written as:

fn func(value: &dyn std::any::Any) { ... }

func(box.as_ref());

Previous suggestion:

fn func(value: &dyn std::any::Any) { ... }

Could be written as:

fn func(value: &dyn MyTrait) { ... }

[y21]

I don't see an inherent issue with this general pattern. Functions are natural abstractions for splitting up code and sometimes you just have to deal with dyn Any (like, panic payloads are the first thing that came to my mind) and want to refactor something out into its own function. For instance (some random code snippet I found from a github code search): https://github.com/astral-sh/rye/blob/7c4b6991e81e0c6885fac846cc76f8a4425de130/rye/src/utils/panic.rs#L4

That looks like a perfectly fine thing to do and it seems odd to me that clippy should blanket-warn all such functions.

Since &Box<Any> itself implements Any, it can easily happen that one accidentally passes the box directly instead of the desired box.as_ref(). This can be the cause of quite hard to debug issues.

This OTOH makes more sense as a lint to me I think -- passing &Box<dyn Any> to a function accepting &dyn Any. Sounds similar to the sort of mistake that type_id_on_box catches.

[Centri3]

Yeah I think making it more specific is better, that's a very valid reason to lint these but the general pattern is okay

[Wumpf]

Makes a lot of sense to me, lint for passing &Box<dyn Any> is a much more general problem and less opinionated/domain specific