assume, assert, enforce, @safe

[bearophile via Digitalmars-d]

Daniel Murphy:

> This doesn't need a lot of text to explain either: "when 
> possible, the compiler will check preconditions at compile time"

What defines "possible"? A compiler switch that allows to define 
the amount of compile time?


> I feel like you're confusing this pull request with another 
> enhancement. The discussion should be about whether this exact 
> feature is worthwhile, not if some other feature would solve 
> some other problems.

The comparison of the two ideas is useful, because they try to 
solve the same problem.


> Do you really think the compiler opportunistically checking
> preconditions would be a bad thing for D?

I think that adding an undefined, growing, compiled-dependent 
list of static checks that can cause unpredictable compilation 
times is not a good idea. A more general solution has some 
advantages:
- It allows the user to choose what to run at compile-time and 
what at run-time;
- You can defined _exactly_ what it does in a book, unlike the 
growing list;
- Will not grow in features and implementation complexity as 
compilers improve (and I think it's sufficiently simple);
- It's going to be mostly the same in all D compilers;
- It allows to specify and run arbitrary tests in CTFE instead of 
a set of predefined by unknown simple tests. So you can use it 
for SafeIntegers literals, and many other future and 
unpredictable purposes;
- It's explicitly visible in the code, because there is a syntax 
to denote such static testing parts in the code.

Implementing a special-cased solution instead of a more general 
and principled solution could make the implementation of the 
better solution more unlikely :-)

Bye,
bearophile