Another idiom I wish were gone from phobos/druntime

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 5 02:01:19 PST 2015


"Jonathan M Davis via Digitalmars-d"  wrote in message 
news:mailman.6014.1423124756.9932.digitalmars-d at puremagic.com...

> 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. 



More information about the Digitalmars-d mailing list