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.

Reply via email to