"IndexType" for ranges

[monarch_dodra]

On Tuesday, 2 October 2012 at 16:59:38 UTC, Jonathan M Davis 
wrote:
> On Tuesday, October 02, 2012 18:45:50 Peter Alexander wrote:
>> On Tuesday, 2 October 2012 at 16:29:28 UTC, Simen Kjaeraas 
>> wrote:
>> > On 2012-10-02, 18:09, Peter Alexander wrote:
>> >> On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra
>> >> 
>> >> wrote:
>> >>> If you've ever worked on a template that needs to index a
>> >>> range, you may have run into this problem: What is the type
>> >>> you should use to index an RA range?
>> >> 
>> >> Forgive my ignorance. What's wrong with size_t?
>> > 
>> > That not all ranges use it? If the range uses int, short, 
>> > byte
>> > (I wonder why they'd do it, though), using size_t will not 
>> > even
>> > compile.
>> 
>> That's kind of my point. Unless there's a compelling reason not
>> to, I'd suggest we standardise on size_t indexing (and length)
>> and avoid this issue altogether.
>> 
>> C++ containers have a size_type typedef. No one uses it.
>> 
>> Let's keep things simple instead of complicating things for the
>> sake of unwanted "flexibility".
>
> In general, all ranges _should_ use size_t for both length and 
> indexing, but
> for a few range types in Phobos specifically use ulong (e.g. 
> IIRC iota does in
> order to work properly with ranges or long and ulong on 32-bit 
> systems). I see
> _zero_ reason to support lengths or indices smaller than 
> size_t. Types that do
> that are badly designed IMHO. But we already have a precedent 
> that you can't
> always assume size_t (at least for length - I'm not sure about 
> indices - but
> if length can be specifically ulong and the type is random 
> access, then its
> indices will need to be ulong), so unfortunately, the situation 
> is not so
> simple that you can always assume size_t (even you should 
> arguably be able
> to).
>
> - Jonathan M Davis

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.