Weird issue with std.range.iota.length

[Meta via Digitalmars-d]

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));
}