DIP 1006 - Preliminary Review Round 1

[12345swordy]

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.