"IndexType" for ranges

[monarch_dodra]

On Tuesday, 2 October 2012 at 16:48:34 UTC, Peter Alexander wrote:
> Then don't create ranges that use ushort for indexing and 
> length. There's no need to.
>
> To be clear, I'm suggesting that all random access ranges 
> should use size_t, and they will not be random access ranges if 
> they use anything else. Unless someone can give a compelling 
> reason not to do this, I cannot see anything but benefits.

I don't know, forcing an implementer on size_t is pretty 
gratuitous. Why can't he be free to choose his own index type?

Besides, you'll still run into the problem for ranges that use 
ulong, such as iota.

Then what about ranges that use ulong? As those wrong too? What 
about iota? Wrong?

//----
import std.range;
import std.algorithm;

void main()
{
     auto r = assumeSorted(iota(0L, 1L)); //Still DERP!
}
//----
src\phobos\std\range.d(6925): Error: cannot implicitly convert 
expression (this._input.length()) of type ulong to uint
src\phobos\std\range.d(7346): Error: template instance 
std.range.SortedRange!(Result,"a < b") error instantiating
//----

And this time, you can't blame me for doing fishy code, it's all 
in phobos.

The end problem is this.

//----
struct S(R)
{
     //...
     auto opIndex(some_type n)
     {
         return r[r];
     }
}
//----
Regardless of what you do, you will encounter problems at the 
"boundaries" or S.opIndex. Either for calling it, because 
some_type is too small, either for implementing it, because 
some_type is too big.

The fact that both uint, ulong and size_t are valid indexers for 
range means ANYTHING in Phobos can break.

The trait I'm proposing should enable support for uint, ulong and 
size_t, and every other type as an added bonus.