TLDR: Some allowed-by-default lints are close enough to the warn-by-default bar to be useful in most cases, but don't hit the bar yet to be warn-by-default for all. Users who are willing to pay the downsides of those lints for their benefits would have a better experience using a lint group rather than going through the list of allowed-by-default lints every 6 months to cherry-pick those close to the warn-by-default bar.
Note: This post has been edited, see the history section for explanation.
Users who would like to improve their code have a hard time discovering lints. And even worse, say they find a list of allowed-by-default lints they want to enable, they still need active work to keep that list up-to-date as the compiler adds new allowed-by-default lints.
Some users are fine with some level of false positive to improve their code. But they have no way to warn on allowed-by-default lints except by going through each of them one by one, thus going back to the discoverability and maintenability problem.
Even worse, there are lints that are currently allowed-by-default but are intended to be warn-by-default at some point with high probability (e.g.
unsafe-op-in-unsafe-fn). The main reasons for not being warn-by-default now being that they would trigger on a large amount of existing code, still have some false positives, and/or nobody got the time to do it. Users should have the option to early opt-in those lints, but they can't without going through them one by one, going back to the discoverability and maintenability problem.
If there would be such pedantic lint group, users could easily discover and keep up-to-date with new lints. The workflow would look like this:
- A user starts a new crate (or wants to improve an existing crate).
- They add
#![warn(pedantic)]to their crate.
- As they develop (or as a one-time cleanup) and each time a lint triggers, they decide whether they care about that lint. If yes, they fix and improve their code. If no, they add
- As they passively maintain their crate, CI will break (usually on nightly) due to a new lint. The developer will decide whether they care about that lint. If yes, they fix and improve their code. If no, they add
- As they decide to do active maintenance (e.g. once a year), they go through the list of allowed lints at the root of the crate, and decide again if anything changed.
Note that I'm only talking about Rust lints. Clippy lints already solve this issue by providing a partition of their lints in a small number of meaningful groups. And in particular they have a pedantic lint group.
Original title was "Lint group for allowed-by-default lints that should ideally be warn-by-default". It has initially been modified to "Should we have a pedantic lint group?" to avoid having to decide whether a lint should ideally be warn-by-default or not, since it may be a slow and difficult process. It should be cheap to modify this new lint group because only opt-in users will be impacted, otherwise it defeats its purpose of accelerating uncertain lints providing access to early adopters.
It has later been modified to "Lint group for lints slightly below the warn-by-default bar" to focus on what the lint group should be and whether it's at all useful, punting the naming question for later. For example, those names are not great:
- "all" or "everything": because the lint group should not contain deprecated lints
- "pedantic": because it may have a "strictly follow the standard" connotation from C (although clippy doesn't use it in that sense)