Writing out a `&Box<T>` type

[oli-obk]

any &Box<T> can also be a &T, and &T is much more general.

I don't see any use in ever writing &Box<T>

[scott-linder]

I would like to give this a shot. Would this fit in the types mod, maybe under types::TypePass? Also, does this apply to mutable references to Box<T>?

[scott-linder]

I went ahead and tried this on my own at scott-linder/rust-clippy@9afc8c933. I hope this is in the ballpark, and I look forward to feedback on it.

[Manishearth]

looks okay to me! Might have been better to add a suggestion but it occurred to me that the suggestion can't be applied without changes elsewhere (to make the types match up) so I'm unsure if we should. Maybe we should, and differentiate with rust-lang/rust#39254 whenever that happens

[scott-linder]

Awesome! Thank you for taking a look.

I agree that the suggestion seems redundant in this case if it is not the full type, but I didn't know if it was possible to omit it.

I also notice that this lint is behind #[warn(box_vec)] on by default, but I do not know where that name comes from.

[oli-obk]

You accidentally used BOX_VEC instead of BORROWED_BOX here

[scott-linder]

Thank you, I pushed up the fix to the same branch.

I believe that was the only other problem I noticed by myself; if you are happy with it I can open a PR, otherwise let me know what else could be changed (including any change or removal of the suggestion).

[oli-obk]

if you are happy with it I can open a PR,

yes, please do so.

In the future you can open a PR even when you still have questions. Then we can discuss them directly on the PR.

[jonas-schievink]

This issue applies to &String and &Vec<T>, too. I've seen both patterns used by quite a few people new to Rust. Or should I open a separate issue for that?

[mcarton]

We already have a lint (ptr_arg from memory) for &String and &Vec<T> 🎉

[jonas-schievink]

@mcarton Nice, thanks!