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.
