Contracts, Undefined Behavior, and Defensive,Programming
Jesse Phillips
Jesse.K.Phillips+D at gmail.com
Sun Jun 14 17:38:34 UTC 2020
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.
More information about the Digitalmars-d
mailing list