DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi]

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