div0: >Well for a start, you lose half your addressable memory.<
This matters mostly with char/ubyte/byte arrays on 32 bit systems. If you have arrays of shorts, ints or pointers/references or you are on 64 bit systems this is not so important. And the extra safety it gives me is a price I can pay. And if you don't want to pay that addressable indexes price you can use longs on 32 bit systems :-) >unsigned numbers are only a problem if you don't understand how they work, but >that goes for just about everything else as well.< This can help you understand why you are very wrong: "Array bound errors are a problem only if you don't understand how arrays work." I have understood how unsigned numbers work, but I keep writing some bugs once in a while. >Personally I hate the use of signed numbers as array indices; it's moronic and >demonstrates the writers lack of understanding.< I am not moronic, and C# designers are smart people. >It's very rare to actually want to index an array with a negative number.< That's beside the main point. The main problems come from mixing signed and unsigned values. > c.f. > > Item getItem(int indx) { > if(indx >= 0 && indx < _arr.length) > return _arr[indx]; > throw new Error(...) > } > > vs. > > // cleaner no? > Item getItem(uint indx) { > if(indx < _arr.length) > return _arr[indx]; > throw new Error(...) > } The second is shorter (and one less test can make it a bit faster) but it's not cleaner. >Using 'int's doesn't magically fix it. Wrong code is just wrong.< I agree. But ints can avoid some bugs. >Hasn't that been discussed before?< Discussions about signed-unsigned-derived troubles have happened before. But this time I have expressed a focused request, to turn indexes and lenghts into signed words (as I have written in my enhancement request). I think this was not discussed before in a focused way (or I was not present yet). Bye, bearophile