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'.
/Paolo
