@trusted assumptions about @safe code
Nathan S.
no.public.email at example.com
Wed May 27 20:04:08 UTC 2020
On Tuesday, 26 May 2020 at 07:07:33 UTC, Timon Gehr wrote:
> I don't think so. @trusted code can't rely on @safe code
> behaving a certain way to ensure memory safety, it has to be
> defensive.
I'd say it's sound to rely on any postconditions in a function's
`out` contract. Those can be mechanically enforced. I'd also say
it's sound for @trusted code to rely on the behavior of a
function whose source code the author of the @trusted code has
reviewed and either has control over or can prevent from changing
(such as by specifying a library version in a dependency manager).
I'd also say it's within the spirit of @trusted to rely on the
behavior of any function that allegedly adheres to a
specification and has been blessed by some expensive certifying
body or meticulous review process as meeting that specification.
After all, all @trusted is (including the @trusted the author is
applying to his own function) is some human's statement that he
has carefully inspected some function and can vouch that calling
it won't cause memory corruption / undefined behavior for a
program that wasn't already in an invalid state.
More information about the Digitalmars-d
mailing list