Bikesheds to be done when RfCing clippy

[Manishearth]

At some point I wish to RfC the clippy lints.

One part of this will be figuring out Allow/Warn defaults. It will also be bikeshedding various questionable choices clippy has made.

Feel free to list anything you find bikesheddable here:

• match_ref_pats on if let (is if let &foo = bar okay?) ; "if let &foo = bar" triggers match_ref_pats #532
• Glob enum imports: warn or allow? https://github.com/Manishearth/rust-clippy/pull/581
• Two-branch matches: warn or allow? https://github.com/Manishearth/rust-clippy/pull/579
• shadow_unrelated: warn or allow
• lints for specific libraries (e.g. Regex: Inform user about slow regex! macro #595): yay or nay?
• redundant closure: warn or allow? There is something to be said for the added clarity of knowing how many arguments there are.

[Manishearth]

See also: #541

[llogiq]

Another thing is shadow_unrelated – I consider those programmer lazyness, but I found so many matches in the wild that I haven't found the courage to make it warn by default.

[Manishearth]

😄 I'm 👍 for warning it now if you want, btw, but yeah, it's something that we should list here.

[nagisa]

Two-branch matches: warn or allow?

Obviously allow. That’s purely a programmer/style-preference thing.

Glob enum imports: warn or allow?

Also allow?

fn a() {
     use Enum::*;
     // do a lot with the variants.
}

is pretty common, though I’m not sure if this exact pattern is linted against.

[oli-obk]

@nagisa only glob imports at the module level are linted against. The question is whether to also not lint on pub use Enum::*; since that also seems to be a common pattern for old-style enums.

[oli-obk]

That’s purely a programmer/style-preference thing.

@nagisa I changed the lint to only trigger if the second arm is a block. In that case it's both more vertical space AND more indentation when using a match instead of an if let.

[Manishearth]

I changed the lint to only trigger if the second arm is a block

This is still preference/style based.

[leoyvens]

Allow cyclomatic_complexity, there is no universal answer to how complex is too complex. Allow explicit_iter_loop, &x is more concise but x.iter() is more explicit, not obvious which is more readable.

[mcarton]

When I made a PR to fix all Clippy warnings in Cargo, they asked me to remove my commit about explicit_iter_loop because they preferred x.iter() over &x.

[leoyvens]

toplevel_ref_arg should be allowed for let bindings, it's purely stylistic, let ref x = expr can be more readable than let x = &expr when expr is complex (for example a long match).

[Manishearth]

#1043 is bikesheddable