"IndexType" for ranges

[Jonathan M Davis]

On Tuesday, October 02, 2012 19:10:53 monarch_dodra wrote:
> Given your stance of "I see _zero_ reason to support lengths or
> indices smaller than size_t" and "Types that do that are badly
> designed IMHO":
> 
> Are you agreeing with my proposed type tightening? If anything,
> it weeds out the "bad designs" for which you had no wish to
> support, while allowing better support for those that do.

Ideally, only size_t would be allowed. Reality makes it so that we need ulong 
in some cases (e.g. iota). Given that fact, you'd ideally restrict it to 
size_t or ulong specfically (or at least IndexType.sizeof >= size_t.sizeof). 
The problem is that I'm quite sure that there are plenty of programmers out 
there who have been using int for length and indices even though it's a 
horribly bad idea. It's a classic mistake. So, while requiring size_t or ulong 
would be great, I'd be very surprised if it didn't break a fair bit of code 
out there. Given that fact that and Andrei's increased resistance to potential 
code breakage, I don't know that we can make that change.

Still, I'd try to push for it though. It's bad enough that length and indices 
are allowed to be something other than size_t at all, but anything smaller 
than size_t (including using int specifically) _will_ cause problems for those 
who do that, if nothing else because size_t is ulong on 64-bit systems and 
using int will therefore mean that code using int for length will likely break 
when compiled on 64-bit systems (particularly when interacting with arrays). 
That's probably even a good argument for why we could restrict length and 
indices to size_t or greater even if it might break code (since it'll 
generally break when compiled on 64-bit systems anyway). This sort of change 
is going to have to get passed Andrei though, so we'll need his buy-in no 
matter what we do.

- Jonathan M Davis