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.
