DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

On 05.03.2018 20:41, Iain Buclaw wrote:
> On Monday, 5 March 2018 at 15:48:12 UTC, Timon Gehr wrote:
>>
>> - Using existing assertions as compiler hints is not necessary. 
>> (Without having checked it, I'm sure that LDC/GDC have a more suitable 
>> intrinsic for this already.)
>>
>> As far as I can discern, forcing disabled asserts to give compiler 
>> hints has no upsides.
>>
> 
> 
> In the simple cases, or in anything that looks like a 
> unittest/testsuite, probably not.
> 
> There are likely going to be more aggressive optimizations however if 
> CFA can see that a variable will never be outside a given range, i.e:
> ...

(Note that by "forcing", I mean withholding other options from the user. 
I'm not saying that using information from asserts can never be useful, 
just that it can just as well be harmful, and therefore it is unwise to 
not allow disabling them. I was saying that there are no upsides to not 
having a flag that actually removes assertions.)

> ---
> int[5] arr;
> 
> if (len < 0 || len >= 5)
> {
>      unreachable();  // in non-release code, this would throw a RangeError.
> }
> 
> return arr[len];
> ---
> 
>  From this, we aggressively assume that len is a valid index of arr.  
> Something that happens in optimized non-release builds, but in release 
> builds we must accommodate for the possibility of a range error.

I think this particular case is a bit less questionable than doing the 
same for general assertions (for instance, in @safe code, -release will 
not actually remove the bounds check unless there is some relevant 
assertion somewhere). In any case, I don't argue strongly against a flag 
that turns all assertions into compiler hints, I just think there should 
also be a flag that disables them safely. Also, maybe -release should 
commit to either disregarding @safe completely or respecting it completely.