number ranges

[Ali Çehreli]

On 1/21/22 08:58, Salih Dincer wrote:

 > ```d
 > auto inclusiveRange(T)(T f, T l, T s = cast(T)0)
 > in(!isBoolean!T) {

'in' contracts are checked at runtime. The one above does not make sense 
because you already disallow compilation for 'bool' below.

You could add a template constraint there:

auto inclusiveRange(T)(T f, T l, T s = cast(T)0)
if(!isBoolean!T) {

(Note 'if' vs. 'in'.)

However, people who instantiate the struct template directly would 
bypass that check anyway.

 >    static assert(!isBoolean!T, "\n
 >        Cannot be used with bool type\n");
 >    if(!s) s++;
 >    return InclusiveRange!T(f, l, s);
 > }

 >    bool opBinaryRight(string op:"in")(T rhs) {
 >      foreach(r; this) {
 >        if(r == rhs) return true;
 >      }
 >      return false;
 >    }

Ouch! I tried the following code, my laptop got very hot, it's been 
centuries, and it's still running! :p

   auto looong = inclusiveRange(ulong.min, ulong.max);
   foreach (l; looong) {
     assert(l in looong);
   }

 >    size_t length() inout {
 >      auto len = 1 + (last - first) / step;
 >      return cast(size_t)len;
 >    }

Does that not return 1 for an empty range?

Additionally, just because we *provide* a step, now we *require* 
division from all types (making it very cumbersome for user-defined types).

 >    // Pi Number Test
 >    auto GregorySeries = inclusiveRange!double(1, 0x1.0p+27, 2);

Very smart! ;) So, this type can support floating point values if we use 
that syntax.

Ali