@trusted attribute should be replaced with @trusted blocks

Patrick Schluter Patrick.Schluter at bbox.fr
Thu Jan 16 10:44:56 UTC 2020


On Wednesday, 15 January 2020 at 23:24:38 UTC, IGotD- wrote:
> On Wednesday, 15 January 2020 at 23:01:57 UTC, Joseph Rushton 
> Wakeling wrote:
>>
>> Presumably your programs are therefore self-crafted binary, 
>> since you couldn't possibly trust the humans who wrote the 
>> standard library to write valid code, or the compiler writers 
>> to translate it correctly into machine instructions? :-)
>>
>
> @safe is a subset of D that guarantees no memory corruption. 
> The only way to ensure this is if the compiler have all the 
> source code (will object code also work?) and can check that 
> all the calls are also @safe. If this condition is not met, it 
> is not safe by definition. @trusted code has reduced memory 
> guarantees and can also call unsafe code further along the line 
> and therefore unsafe.

No, that's where you're wrong. @trusted gives the same guarantees 
than @safe. The only difference is that @safe can automatically 
be checked and @trusted cannot. ANY memory violation in a trusted 
code is a BUG and the responsibility of the programmer.
That's why @trusted is important and should be only applied to 
the parts that cannot be checked by the compiler.
Why limit then @trusted block to functions and not to scopes? Imo 
the call interface has a semantic that does not allow (or at 
least not encourage) to interact directly with data of the 
callers scope. All interactions have to be done via parameters 
which scopes and lifetimes are known. This is not the case with 
simple scopes. So the difference between the two is the ABI which 
adds some guarantees that a simple scope cannot (see Steven 
Schveighofer's example).






More information about the Digitalmars-d mailing list