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