On Saturday, December 29, 2012 02:18:36 Peter Alexander wrote: > There was a discussion a while ago about the type returned by > .length for ranges. I believe the conclusion was that it should > always be size_t. > > My question now is what to do with really large ranges? For > example, if we have a range of permutations of the elements in a > set, when the set is larger than 21 the number of permutations is > 21 factorial, which is over 2^64. As far as I see, there are > three options: > > 1. Allow ranges to return BigInt for length. > 2. Allow ranges like this but assert when .length overflows. > 3. Allow ranges like this and just allow .length to overflow > dangerously. > 4. Do not allow ranges like this. > > Option 1 solves the problem, but significantly complicates Phobos > development for the rare case. > > Option 2 works, and is practical, although runtime asserts are > undesirable. > > Option 3 is current Phobos practice (presumably because overflow > is unlikely). See example below. This may be acceptable > currently, but perhaps less so when overflow is more likely. > -------------------------------- > auto a = iota(size_t.max / 2 + 1); > auto b = chain(a, a); > writeln(a.length); // 9223372036854775808 > writeln(b.length); // 0 > -------------------------------- > > Option 4 works, but it would be a shame to lose these ranges. > > Thoughts?
I'd be very strongly inclined to go with #4 and just say that anyone who actually cares about numbers that large should use 64-bit. Needing ranges of length greater than uint.max is definitely not the norm, and I would expect people caring that much about computational stuff to be using 64-bit anyway, since odds are they'll need the memory. Allowing for length to be anything other than size_t is extremely annoying for generic code. - Jonathan M Davis
