✅️Option<&T>; ❌️&Option<T>

[Rudxain]

What it does

Title says it all, but it could be extended to Result and other enums

Advantage

helix-editor/helix#11091

Drawbacks

If a lib has this lint, it could lead to public API breakage. However, it may be worth it, considering this lint could prevent further breakages

Example

fn f<T>(a: &Option<T>) {
    let _ = a.as_ref();
}

Could be written as:

fn f<T>(a: Option<&T>) {
    let _ = a;
}

[Rudxain]

I've already (on the Helix PR) linked to Logan Smith's video. I didn't include it here, because I thought it was redundant

[nyurik]

There is already a ref_option_ref lint that suggests this change:

// bad
let x: &Option<&u32> = &Some(&0u32);
// good
let x: Option<&u32> = Some(&0u32);

I guess it focuses on the internal code, whereas this issue is about fn signature, but if it is expanded to enums and other places, it might make sense to either split them into multiple lints, or rethink the whole approach?

[nyurik]

@rustbot claim

[nyurik]

@Rudxain I implemented rough draft of this in #13336 - but it could use some unit tests. If you have some time, could you provide a few to ensure it works well? Thx!

[Rudxain]

it could use some unit tests. If you have some time, could you provide a few to ensure it works well? Thx!

Do you mean snippet examples? Or do I have to locally build the fork and test clippy on some "real" code?

If I understood correctly, you mean internal test cases for the functions that the lint depends on. Am I right?