@trusted attribute should be replaced with @trusted blocks

Johannes Pfau nospam at example.com
Wed Jan 15 21:08:01 UTC 2020

Am Wed, 15 Jan 2020 20:14:13 +0100 schrieb ag0aep6g:

> On 15.01.20 19:41, Joseph Rushton Wakeling wrote:
>> Well, apologies to Steven if I've misinterpreted his proposal. But what
>> I had in mind was that @safe would be able to call @trusted just as it
>> does now.
>> So, put that together with what I wrote above, and you have something
>> that allows better validation of the internals of @trusted functions,
>> and still gives the user clarity about which functions are safe in
>> their own terms, and which are safe based on some programmer provided
>> guarantees.
> You're saying that an @safe function `f` is somehow more guaranteed to
> be safe than an @trusted function `g`, even though `f` may be calling
> `g`. I don't see how that makes sense.
> ----
> R f(P params) @safe { return g(params); }
> R g(P params) @trusted { /* ... whatever ... */ }
> ----
> Any assumptions you have about `f` better also be true about `g`.

A trusted function in D is supposed to have a safe interface: For each 
possible combination of argument values, a trusted function must not 
cause invalid memory accesses. This is the only reason you can safely 
call trusted functions from safe functions. It's the programmers 
responsibility to design trusted function APIs in a way so they can't be 


More information about the Digitalmars-d mailing list