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
