Weird issue with std.range.iota.length

[Steven Schveighoffer via Digitalmars-d]

On 2/12/16 10:59 AM, Jonathan M Davis wrote:
> On Friday, 12 February 2016 at 14:36:29 UTC, Meta wrote:
>> On Friday, 12 February 2016 at 08:11:57 UTC, Jonathan M Davis wrote:
>>> What it comes down to is that length should always be size_t. That's
>>> what it is for arrays, and that's what most code expects. Allowing
>>> other types just causes trouble for generic code. However, in the
>>> case of iota with long, if length is size_t, then on 32-bit systems,
>>> it's possible to have a range from iota which is longer than size_t
>>> can represent (much as it would normally be crazy to have a range
>>> that long). So, at some point, someone made it so that iota uses
>>> ulong for length instead of size_t when it's a range of longs or
>>> ulongs. It's the only thing in Phobos that does, and it causes
>>> problems. Changing it back to size_t has been discussed but not
>>> agreed upon. But we're between a rock and a hard place with this one.
>>> There is no clean solution.
>>>
>>> Personally, I'd very much like to see iota just always use size_t for
>>> length like every other range (the only ranges which would be
>>> affected would be ludicrously long anyway, and it would only affect
>>> 32-bit programs). But that hasn't happened yet, so iota over longs
>>> and ulongs doesn't behave nicely on 32-bit systems.
>>>
>>> Regardless of which way we go, the problem will _eventually_ go away
>>> when 32-bit systems finally die out, but that's likely to take a while.
>>>
>>> - Jonathan M Davis
>>
>> What about adding another overload of iota, say, iotaEx or something
>> along those lines. All it would do is the following:
>>
>> auto iotaEx(B, E)(B begin, E end)
>> {
>>     assert(unsigned(end - begin) <= size_t.max);
>>
>>     static struct Result
>>     {
>>         typeof(iota(begin, end)) payload;
>>
>>         @property size_t length()
>>         {
>>             return cast(size_t)payload.length;
>>         }
>>
>>         alias payload this;
>>     }
>>
>>     return Result(iota(begin, end));
>> }
>
> It would be far better IMHO to just do a check in iota and throw a
> RangeError if the length wouldn't fit in size_t. Having length ever be
> anything other than size_t is just going to cause problems with other
> ranges. On 32-bit systems, you lose out on the ability to have a range
> that covers all values of long or ulong, but that's of very limited
> usefulness anyway, and as long as the number of elements is no greater
> than size_t.max, it would be fine - which would cover virtually all use
> cases. No, it's not perfect, but allowing length to be anything but
> size_t just causes bugs - especially in generic code.

Just because you have a range with a ulong length doesn't mean you are 
going to iterate the entire thing.

What we need is this:

standardLength(R)(R r) if (isInputRange!R && hasLength!R)
{
    static if(is(typeof(r.length) == size_t)) return r;
    else
    {
       static struct Result
       {
          R wrapped;
          size_t length() { return to!size_t(wrapped.length); }
          alias wrapped this;
       }
       return Result(r);
    }
}

-Steve