assume, assert, enforce, @safe

[Timon Gehr via Digitalmars-d]

On 08/02/2014 02:04 AM, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Aug 02, 2014 at 01:59:29AM +0200, Timon Gehr via Digitalmars-d wrote:
>> On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
>>> OTOH, perhaps one way to work around this, is to have a function with
>>> an in-contract compile into a preamble and a body:
>>>
>>> 	int func(int x)
>>> 	in { assert(x > 5); }
>>> 	body {
>>> 		return computeResult(x);
>>> 	}
>>>
>>> would compile to the equivalent of:
>>>
>>> 	int __func_incontract(int x) {
>>> 		assert(x > 5);
>>> 		goto __func_body;	// fall through to __func_body
>>> 	}
>>> 	int __func_body(int x) {
>>> 		return computeResult(x);
>>> 	}
>>>
>>> In non-release mode, calls to func would get translated into calls to
>>> __func_incontract,
>>
>> What if a library function was compiled in release mode?
>
> The compiler always emits the in-contract,

I know.

> so the library would carry all the in-contracts.

Indeed.

> If the user code doesn't actually use them, then
> the linker just doesn't link them in at link time.
> ...

I was trying to half-jokingly make a pedantic point about the nature of 
"the equivalent of: [...] assert(x > 5); [...]" in release mode.

Another issue is that if one just emits the above lowering, the 
optimizers might not be able to assume the in contract correct on entry 
of __func__body without further precautions.