RFC: Value range propagation for if-else

[bearophile via Digitalmars-d]

Meta:

> My point exactly. If contracts allow things like what 
> Bearophile wants to work, then people might use them to do 
> input/output validation instead of validating basic 
> assumptions, like they're supposed to do. Then we have problems 
> like you described. Maybe it's a good idea to keep contracts 
> as-is and not allow them to change a function's semantics like 
> this, since they are removed in release.

This is an interesting topic.

D contracts are a potentially important language feature that is 
currently underused, perhaps because it's currently a little more 
than a nicer place to locate asserts (and it still lacks the 
pre-state ("old") feature).

Function contracts don't change the program semantics, they 
define part if it at a higher level than the function body itself.

When your function has a post-condition that specifies the 
function to return a value between 0 and 9 inclusive, your 
function is defined to return such range, that's its semantics. 
If the function returns something outside that range, then your 
function has a bug. Relying on the function semantics to allow 
casts is one basic usefulness of contracts, but this is just a 
starting point (if take a look at the Whiley language you see 
what I mean: whiley.org ).

If you compile your code with -release you are assuming your code 
doesn't have bugs, and your contracts are always satisfied.

Perhaps D programmers need to stop compiling with -release. 
Perhaps even the name of this compiler switch should be changed 
to something more descriptive of its unsafety and meaning.

The presence of -release compiler switch can't hold back the use 
of contract programming for all it's worth. Currently D is not 
taking its contract programming seriously :-)

Bye,
bearophile