Go through the libz blitz's guidelines checklist

From https://rust-lang-nursery.github.io/api-guidelines/checklist.html

I think a lot of these might not be too relevant since we don't export a very large API. We should go through and check everything off that is irrelevant, and then for relevant items, file sub-issues.

Naming (crate aligns with Rust naming conventions)

• Casing conforms to RFC 430 (C-CASE)
• Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
• Getter names follow Rust convention (C-GETTER)
• Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
• Iterator type names match the methods that produce them (C-ITER-TY)
• Feature names are free of placeholder words (C-FEATURE)
• Names use a consistent word order (C-WORD-ORDER)

Interoperability (crate interacts nicely with other library functionality)

• Types eagerly implement common traits (C-COMMON-TRAITS)
  Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug, Display, Default
• Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
• Collections implement FromIterator and Extend (C-COLLECT)
• Data structures implement Serde's Serialize, Deserialize (C-SERDE)
• Types are Send and Sync where possible (C-SEND-SYNC)
• Error types are meaningful and well-behaved (C-GOOD-ERR)
• Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
• Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)

Macros (crate presents well-behaved macros)

• Input syntax is evocative of the output (C-EVOCATIVE)
• Macros compose well with attributes (C-MACRO-ATTR)
• Item macros work anywhere that items are allowed (C-ANYWHERE)
• Item macros support visibility specifiers (C-MACRO-VIS)
• Type fragments are flexible (C-MACRO-TY)

Documentation (crate is abundantly documented)

• Crate level docs are thorough and include examples (C-CRATE-DOC)
• All items have a rustdoc example (C-EXAMPLE)
• Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
• Function docs include error, panic, and safety considerations (C-FAILURE)
• Prose contains hyperlinks to relevant things (C-LINK)
• Cargo.toml includes all common metadata (C-METADATA)
  authors, description, license, homepage, documentation, repository, readme, keywords, categories
• Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
• Release notes document all significant changes (C-RELNOTES)
• Rustdoc does not show unhelpful implementation details (C-HIDDEN)

Predictability (crate enables legible code that acts how it looks)

• Smart pointers do not add inherent methods (C-SMART-PTR)
• Conversions live on the most specific type involved (C-CONV-SPECIFIC)
• Functions with a clear receiver are methods (C-METHOD)
• Functions do not take out-parameters (C-NO-OUT)
• Operator overloads are unsurprising (C-OVERLOAD)
• Only smart pointers implement Deref and DerefMut (C-DEREF)
• Constructors are static, inherent methods (C-CTOR)

Flexibility (crate supports diverse real-world use cases)

• Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
• Caller decides where to copy and place data (C-CALLER-CONTROL)
• Functions minimize assumptions about parameters by using generics (C-GENERIC)
• Traits are object-safe if they may be useful as a trait object (C-OBJECT)

Type safety (crate leverages the type system effectively)

• Newtypes provide static distinctions (C-NEWTYPE)
• Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
• Types for a set of flags are bitflags, not enums (C-BITFLAG)
• Builders enable construction of complex values (C-BUILDER)

Dependability (crate is unlikely to do the wrong thing)

• Functions validate their arguments (C-VALIDATE)
• Destructors never fail (C-DTOR-FAIL)
• Destructors that may block have alternatives (C-DTOR-BLOCK)

Debuggability (crate is conducive to easy debugging)

• All public types implement Debug (C-DEBUG)
• Debug representation is never empty (C-DEBUG-NONEMPTY)

Future proofing (crate is free to improve without breaking users' code)

• Sealed traits protect against downstream implementations (C-SEALED)
• Structs have private fields (C-STRUCT-PRIVATE)
• Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
• Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)

Necessities (to whom they matter, they really matter)

• Public dependencies of a stable crate are stable (C-STABLE)
• Crate and its dependencies have a permissive license (C-PERMISSIVE)

Start with the Rust API guidelines checklist and inspect the crate's public API and Cargo.toml metadata. Mark checklist items that are irrelevant to rust-bindgen, then identify relevant gaps and file focused sub-issues for each one. Done means the checklist has been reviewed and follow-up work is clearly scoped.