Contracts, Undefined Behavior, and Defensive,Programming

[Timon Gehr]

On 14.06.20 19:38, Jesse Phillips wrote:
> On Saturday, 13 June 2020 at 15:38:03 UTC, Johannes Pfau wrote:
>>
>> To summarize and rephrase this: the encapsulation unit of @safe is the 
>> function boundary. The parameter definitions (including this pointer) 
>> and return type and their modifiers are the information the compiler 
>> uses to implement it's safety checks. For all possible combinations of 
>> these input values, the @safe function may not cause memory corruption.
>>
>> asserts then narrow the function contract by describing semantic 
>> limitations and @safe is not able to enforce this, as this information 
>> is not part of the function signature. This is fine, as @safe will 
>> still prevent soft UB from escalating to hard UB. But if you now use 
>> assert() as assume(), you introduce hard UB for some possible input 
>> combinations, subverting @safe guarantees.
> 
> Let me try and state the position I think you are taking.
> 
> Soft undefined behavior is unacceptable for @safe code because it can 
> lead to memory corruption due to the hard undefined behavior which may 
> result from the soft undefined behavior.

No, soft undefined behavior is fine. The problem is that assert is 
explicitly specified to cause hard undefined behavior on failure, yet is 
allowed in @safe code.