That’s basically why I use an “almost always (signed) int” approach both in C and Zig and also compile my C code with -Wsign-conversion. Unsigned integers are really only useful for bit twiddling and modulo math, but not for regular values that “can’t be negative” like texture dimensions or array indices, since you’ll inevitably want to compute such values using signed integers (like adding a negative offset to an array index). And yes, I think loop counters, array indices and array/slice lengths in Zig should be signed integers 
PS: also, before that’s coming up: optimizing compilers optimize a signed range check ((i >= 0) && (i < len)) to a single unsigned comparison ((uint)i < len), since the concept of associating an integer value with a persistent “signedness” doesn’t exist down in assembly, instead signedness is a property of a specific operation on sign-agnostic integers.
PPS: I sometimes wonder if languages should have signed/unsigned operators on sign-agnostic integers instead of signed/unsigned integer types - especially now that 2s complement has won - the signedness hint is only needed for sign extension of narrower to wider integers, e.g. whether to fill the top bits with zeroes (for unsigned operations) or with a copy of the MSB (for signed operations.