`deny(warning)` is not an anti-pattern for libs

The main reason why deny(warning) is considered an antipattern, according to the patterns guide, is that a crate author opts out of Rust's stability guarantees, since Rust is allowed to add new warnings to new versions. Thus, new versions of rust may break the crate.

However, rust currently caps the the max lint level to "warn" when building dependencies. Thus, even if a crate specifies #![deny(warning)], the warnings will not be upgraded to denies when it is built as a dependency. See this comment:

I'm actually not sure if that antipattern still applies given that cap-lints exists. The patterns book is old and partially maintained, and cap-lints was not always a thing.

Again, if a crate is a dependency there is no way to cause it to fail to compile by tweaking lint levels.

It's not a huge deal if a crate fails to compile under deny(warnings), if you're building the crate itself you probably are developing on it (not using it as a dep). Except perhaps for binary crates.

As such, deny(warning) is actually an entirely fine pattern for libraries to use. It may be worth amending the deny(warning) antipattern crate to explain that it only applies to binary crates.

CC https://github.com/rust-unofficial/patterns/issues/46