Ranges with length that cannot be named

[berni]

We are used to divide ranges in two: Ranges with length and 
infinite ranges. But there is something in between. Some ranges 
have a length, that does not fit in an (u)long and therefore 
cannot be named in D. The same might be the case, when the 
calculation of the length is somehow problematic.

Think of iota(-5.0,double.max,1.0) or iota(8.5300000000000011, 
438.17803623529841, 0.4296480362352984) - both given in issue 
#18227.

Having thought about this for some time now, I think, there is a 
certain parallel to floatingpoint numbers: We know, that there 
are numbers between 1.0L and 1.0L+real.epsilon but we cannot name 
them.

While we learned to live with the gaps in floatingpoint numbers, 
we don't have an idea on how to cope with those ranges, yet.

When investigating on the subject I often found people claiming, 
that ranges of that length are of no use and therefore we do not 
need to care. But I think, this is not true. Infinite ranges are 
even longer and still usefull. Think of 
iota(...).drop(100).take(50) or similar or in case of random 
access ranges, slicing or accessing some elements.

As long, as the length is not queried, these ranges are usefull. 
And even if the length is queried, the information, that it 
cannot be named, might be sufficient. For me, the question 
therefore is mainly, how to tell the caller of length(), that it 
cannot be named.

Some ideas came to my mind:

a) return 0, but empty()==false
b) throw an Exception
c) return ulong.max (or size_t.max or long.max or whatever type 
is used for the length of ranges)
d) using BigInt

My thoughts on that:

a) Has the advantage, that length() can be nothrow. This solution 
might break existing code, but I think, this affects only code 
that's broken anyway or that uses length instead of empty to 
decide if the range is empty, which is somewhat bad style.

b) Is a clean solution but might add the need for exception 
handling, where in lots of cases no exception is to be expected.

c) On first sight, this doesn't feel good. But meanwhile I think, 
that it might work quite well in practice. (But I'm not sure on 
this and might be completely wrong.)

d) I dislike this approach. Most usecases work with much smaller 
numbers and BigInt would slow them down all. And it still would 
not solve the problem, when calculation is difficult.

Im curious on your oppinion or better ideas. :-)