The Git source code audit, viewed as a Rust programmer

So neither type implements From/Into the other, the best you get are TryFrom/TryInto where you either have to handle an error or discard it after “proving” overflow can’t happen.

This is unambiguously the correct behavior, but it is sort of frustrating at times.

I imagine the nuance here is in the "or something", since that could imply something signed or larger than 32 bits, but for that specific case, I feel like a large amount of code that people write nowadays can be comfortably assumed not to need to run on 16-bit processors. Although `usize `only implements `TryFrom<u32>` and not `From<u32>`, even the standard library documentation for Rust simplifies things by saying that `usize` will be either 4 or 8 bytes (https://doc.rust-lang.org/std/primitive.usize.html), although I understand this isn't a hard contract and could change in the future. I guess it depends a bit on the use case, but I think that most of the time just using `try_from` and panicking with an appropriate error message on error would be fine, and if you want to be extra sure, you can always use something like `const_assert!` (https://docs.rs/static_assertions/1.1.0/static_assertions/ma...) with the `BITS` constant (https://doc.rust-lang.org/std/primitive.usize.html#associate...) to catch it at compile time to be extra certain.

I imagine that applications with less addressing space also have less of every other resource, and can count less of everything.

Fair point, but it really only matters if the overflow is handled gracefully. If it's handled as an unrecoverable error condition, it often 1. doesn't happen during normal operation and 2. can be invoked by a determined attacker, regardless of the exact size. Sure, the exact characteristics might be different, but in the end it doesn't make much of a difference.

Petgraph has a great API, and in general using newtypes over integers for collection indices is a great way to avoid another logic bug: mixing up indices for different collections.

While that may make it platform agnostic, doesn't that make it non-time-agnostic? What I mean is, I lived through the 16-to-32-bit transition. If Rust had been around then, and you wrote code that used u16, and you tried to use it now, you would probably bump against that 16-bit limit. The platforms grew with time, but the code didn't.

We're starting into the 32-to-64-bit transition (we've been slowly easing into it for years, in fact). Don't lock yourself into 32-bit code (unless the algorithm requires it). You're locking yourself out of the future.

There actually is! You can activate the lint with a `#[deny(clippy::integer_arithmetic)]` or by using the lint group `restriction`.[0]

  // https://rust-lang.github.io/rust-clippy/master/index.html#integer_arithmetic
  #[deny(clippy::integer_arithmetic)]

  fn main() {
      let (a, b) = (u32::MAX, 1);
      //let c = a + b; // clippy: `error: integer arithmetic detected`
      let (c, carry) = a.overflowing_add(b); // or any of checked_*, saturating_*, unchecked_*, wrapping_*
      println!("{a} + {b} = {c} (carry bit: {carry})");
      // output: `4294967295 + 1 = 0 (carry bit: true)`
  }

[0]: https://rust-lang.github.io/rust-clippy/master/index.html#in...

Since the git CLI is subcommand-based, it wouldn't be too hard to provide replacements for individual git subcommands one at a time. If you replaced git clone, push, pull, commit, checkout, and rebase, that would suffice for 95% of git invocations.

The compiler can't even imagine what the code should look like, after all this type can't exist, does it fit in a register? How do we perform operations on it? If we try to actually realise an empty type by e.g. dereferencing a pointer to it that somebody gave us from a C API the Rust compiler will reject that as nonsense.