@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