On Tuesday, 6 March 2018 at 17:24:35 UTC, Jonathan M Davis wrote:
On Tuesday, March 06, 2018 16:30:09 John Colvin via Digitalmars-d wrote:
On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote:
> On 3/5/2018 2:30 PM, John Colvin wrote:
>> This just feels bad. Adding extra failsafes for my debug >> program shouldn't make my release program less safe.
>
> Then use `enforce()`.

So, to clarify, adding asserts to my code makes my release builds violate @safe?

If the compiler actually optimized based on assertions, then yes, but not right now. As I understand it, the problem is theoretical at the moment, because the compiler does not yet optimize based on assertions, but once it does, if it's allowed to introduce optimizations that would be not be memory safe if the assertion would have failed if it hadn't been compiled out, then @safe will be violated, and at that point, I would be telling everyone to never use assertions, because they're too dangerous.

If we can restrict the compiler to optimizations that are memory safe, then I don't see a problem, but clearly, Walter is not in agreement that the optimizations should be restricted in that manner.

- Jonathan M Davis

I think a reasonable compromise is to introduce a new system attribute such as @unsafeoptimize to tell the programmer that this function may have it's @safe attribute removed when making optimizations based on the asserts. We have @trusted attribute for a good reason here.

Reply via email to