number ranges

[Ali Çehreli]

On 1/19/22 21:24, Salih Dincer wrote:

 > ```d
 >    size_t length() inout {
 >      //return last_ - first_ + 1 - empty_;/*
 >      auto len = 1 + last_ - first_;
 >      return cast(size_t)len;//*/
 >    }
 > ```

Good catch but we can't ignore '- empty_'. Otherwise an empty range will 
return 1.

 > But it only works on integers.

After fixing the size_t issue, it should work on user-defined types as 
well. In fact, it is better to leave the return type as auto so that it 
works with user-defined types that support the length expression but is 
a different type like e.g. MyDiffType.

Having said that, floating point types don't make sense with the 
semantics of a *bidirectional and inclusive* range. :) Let's see how it 
looks for ranges where the step size is 0.3:

import std.stdio;

void main() {
   float beg = 0.0;
   float end = 1.0;
   float step = 0.3;

   writeln("\nIncrementing:");
   for (float f = beg; f <= end; f += step) {
     report(f);
   }

   writeln("\nDecrementing:");
   for (float f = end; f >= beg; f -= step) {
     report(f);
   }
}

void report(float f) {
   writefln!"%.16f"(f);
}

Here is the output:

Incrementing:
0.0000000000000000
0.3000000119209290
0.6000000238418579
0.9000000357627869
                 <-- Where is 1.0?
Decrementing:
1.0000000000000000
0.6999999880790710
0.3999999761581421
0.0999999642372131
                 <-- Where is 0.0?

So if we add the 1.0 value after 0.9000000357627869 to be *inclusive*, 
then that last step would not be 0.3 anymore. (Thinking about it, step 
would mess up things for integral types as well; so, it must be checked 
during construction.)

The other obvious issue in the output is that a floating point iota 
cannot be bidirectional because the element values would be different.

Ali