Is this reasonable?

[Jonathan M Davis]

On Thursday, December 05, 2013 23:44:33 Brad Anderson wrote:
> On Thursday, 5 December 2013 at 19:36:46 UTC, H. S. Teoh wrote:
> > On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote:
> > [...]
> > 
> >> Cough, cough, make array length be an int.
> >> 
> >> Do you really need arrays that big? :-S
> >> 
> >> (I'm talking to Mr. D Compiler here)
> > 
> > A negative length array makes no sense.
> > 
> > Plus, being a systems language, D should be able to represent
> > an entire
> > 64-bit address space as an array of ubytes (even if this is
> > rarely
> > done!). If one were to write a kernel in D, it would be
> > laughable to use
> > signed array lengths.
> > 
> > 
> > T
> 
> Chandler Carruth of LLVM fame (also on the C++ ISO Committee)
> said during Going Native (it was either his talk or the panel, I
> can't remember which unfortunately) that C++'s decision to make
> size_t unsigned was a big mistake and you should almost always
> use signed integers unless you need two's complement arithmetic
> for some weird reason. I can't remember the entire rationale for
> this though.
> 
> http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s
> -Dragons
> http://channel9.msdn.com/Events/GoingNative/2013/Interactive-Panel-Ask-Us-A
> nything

Don loves to argue the same thing. If all we had to deal with was 64-bit and 
larger, then it would probably be fine, but it's much more debatable with 32-
bit and smaller, as with those architectures, you actually can need the full 
address range for large data sets. 64-bit is large enough that that's not 
going to be an issue - you couldn't even have that much memory to address at 
this point. Maybe someday it could matter but probably not except with 
something like mmap on systems with a ton of hard drives mapped as a single 
drive or somesuch. So, if we only supported 64-bit and larger, then I might 
support the idea of size_t being signed, but as long as we have to worry about 
32-bit, I don't think that that's really an option.

Regardless, we're pretty much stuck at this point. Changing it would silently 
break lots of code. Making the signed/unsigned comparison an error is probably 
our only real option at this point, and that would have the advantage of fixing 
it in all cases where you're mixing signed and unsigned numbers, not just in 
cases where you're dealing with length.

- Jonathan M Davis