"Jonathan M Davis via Digitalmars-d" wrote in message
news:[email protected]...
So, if we can change the semantics of in and out blocks so that they
provide
actual value, then there's definitely value in using them. But until then,
as far as I'm concerned, they're just cruft that should be avoided.
Yes, and we are almost certainly going to change it so that the caller's
flags determine if contracts are executed, not the callee's. That alone is
enough to make explicit contract blocks worthwhile.
Having some sort of compile time checking of contracts would potentally be
a
case where in blocks would be of value, though I really don't see much
difference between checking the assertions in an in block and checking any
other assertions at compile time that can be checked at compile time -
especially if they're at the beginning of a function.
IMO they have a different meaning either way.
void func(int x)
in
{
assert(x > 6); // If this assert fails the caller was incorrect
}
body
{
assert(x > 7); // If this assert fails then 'func' has a bug.
}
While these look similar, they vary in where they assign blame. It would
not be valid for the compiler to give an error at the caller if the second
assert is known to fail, because it's not the caller's fault.
It's not uncommon to stub out unimplemented functions with assert(0), and
this is not an error for the caller either. Without 'in' blocks we lose
this distinction.
The real killer feature would be if we could figure out how to make it so
that contracts are controlled by the call site instead of being compiled
out
when the function itself is compiled without assertions enabled. But I
have
no idea how we could do that given that we can have function prototypes
without the actual source code being visible at the call site.
It's possible, it's just not easy. Contracts would not be called if the
prototype didn't have them, so di files would likely have the contracts
retained.
