RFC: Value range propagation for if-else

[bearophile via Digitalmars-d]

Nordlöw:

> The simplest example is probably the constructor for Bound 
> defined something like

Very good, with this you have framed the discussion well :-)


> - value range information is propagated to the constructor 
> argument `value`

The problem is, I think this is currently false (even if you call 
your constructor with just a number literal). I'd like this 
feature in D, but I don't know how much work it needs to be 
implemented.

D language is designed to allow you to create data structures in 
library code able to act a lot like built-in features (so there's 
a refined operator overloading, opCall, static opCall, and even 
more unusual things like opDispatch), but there are built-in 
features that can't yet be reproduced in library code, observe:


void main() {
     int[5] arr;
     auto x = arr[7];
}


dmd 2.066alpha gives a compile error:

test.d(3,14): Error: array index 7 is out of bounds arr[0 .. 5]


In D there is opIndex to overload the [ ], but its arguments are 
run-time values, so I think currently they have no way to give a 
compile-time error if you use an index that is known statically 
to be outside the bounds. So currently you can't reproduce that 
behavour with library code. Propagating the value range 
information to the constructor, plus the new __trait(valueRange, 
exp), allow to solve this problem. And indeed this allows to 
implement nice ranged values like in Ada, and to do what the 
Static_Predicate of Ada does.


Another common example of what you currently can't do with 
library code:

void main() {
     import std.bigint;
     BigInt[] arr = [10, 20];

     import std.numeric;
     alias I10 = Bound!(int, 0, 10);
     I10[] arr = [8, 6, 20];
}


(In theory the compiler should also catch at compile time that 
bug, because 20 is outside the valid bounds of I10.)


The "enum precondition" I've suggested elsewhere is a 
generalization of that feature (but it's not a strict subset 
because it only works with literals, so it's good to have both 
features), because it manages not just ranges of a single value, 
but also other literals, like an array:


void foo(int[] arr)
enum in {
     assert(arr.all!(x => x < 10));
} in {
     assert(arr.all!(x => x < 10));
} body {
     // ...
}
void main() {
     foo([10, 20]); // gives compile-time error.
}


This is possible only if the source code of foo is available in 
the compilation unit. In presence of separated compilation the 
enum precondition is ignored. So the enum preconditon can't 
replace regular pre-conditions, they are useful to catch 
statically only a subset of bugs. The same happens with the idea 
of propagating range information to the constructors. One way to 
avoid or mitigate this problem is to leave available the source 
code of functions with an enum pre-conditions, just like with 
templates. Perhaps this is not a big problem because enum 
preconditions and constructor value range propagation are meant 
to be used mostly in library code, like in Bound integers, etc.

Bye,
bearophile