> No, that's not the "real issue", if you make `x.len - 3` produce an underflow > instead then common loops like for i in `0..x.len - 4` crash instead of > iterating 0 times...
Relying on `0..s.len-X` iterating 0 times when X>len is not a good practice in my opinion, as it's not clear from the code if the author actually assumed that `len` will always be `>=X` or not. However, I understand it's short, convenient and efficient _when the situation perfectly aligns_ with the code's behaviour. > Well much like C# and Java are "stuck" on their designs that actually work... I actually meant my comment to be rather neutral (that's why I chose a pretty inconsequential comparison). > No, because if the underlying type allows for high(uint) then you cannot > convert that safely to int for signed arithmetics anymore... Well, it kind of explains how the standard library is not very consistent with using `Natural` type for indexing as if a bit unsure it's a good idea. ;) I was wrong as my comment only considered the type's role in indexing. Here's a very solid article in favour of using unsigneds: <https://graphitemaster.github.io/aau>/ (excuse the absence of namedropping). I don't have a strong opinion here, just presenting some alternative arguments here.
