On Tuesday, 6 March 2018 at 17:34:08 UTC, 12345swordy wrote:
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:
> [...]

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.

I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour.

If the program must HALT on this or that, well, what is better than an explicit piece of unremovable code that do that? Instead of writing 'assert', one should write 'enforce'.


Reply via email to