concepts and interfaces

[Dan]

Martin, I personally feel that properly implementing contract programming would envelop any functionality that you're suggesting; as "concepts" only applies to class-oriented programming, and contracts apply to any methods/functions...

I believe a more flexible, powerful, and wide-reaching modification would be to enhance contracts with proper bounds and type declarations *without* asserts - and to have a compiler option that performs proof by induction (by examining potential upstream flow control paths and tracing them back down to the contract to verify all cases are within bounds.  This may also identify infinite loops and such)

For example, *something* like:

invariant {
  x // is within the realm of 0..int.max - 3
  i < myArray.length; 
}
x += 3; // would normally cause an overflow if x is (int.max-3)..int.max

In this way, many kinds of proveable constraints can be performed on information flowing through these constraint blocks at compile time via proof-by-induction; instead of performing asserts/ifs whenever.  

Those that can't be proven at compile time could optionally be examined at runtime (asserts/ifs), examined by the programmer to see if they're "going to be reasonable, don't bother checking at runtime" or whatnot.

Implementing this would make code *proveable* which dramatically increases the power of programmers during the debugging cycle such that "what the heck is it doing wrong?" is replaced with "so exactly what am I allowing it to do?"