@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