@trusted attribute should be replaced with @trusted blocks

Timon Gehr timon.gehr at gmx.ch
Thu Jan 16 00:14:05 UTC 2020

On 16.01.20 00:24, 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.

@safe does not mean "this unconditionally can not corrupt memory", it 
says "if its @trusted dependencies are written right, @safe code can not 
introduce memory corruption". If you don't write @trusted code yourself 
and only use the standard library, @safe gives you the guarantee you 
mention per the language and standard library specification, but in 
practice there can be bugs in the language implementation or its 
dependencies. Assuming a correct compiler implementation of the safety 
checks, the locations where memory corruption can be caused will however 
all be within `@trusted` function calls.

Similar concerns apply to other safe languages such as Java. (Why do you 
think users need to update their JVM regularly? It's not just about 
performance upgrades.) What do you think "security updates" for your OS 
do? How is @safe supposed to be _useful_ if it cannot assume the OS, 
system C libraries, and hardware behave as specified?

> 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.
> @trusted is therefore impossible and the criteria cannot be met. It's 
> just a badge meaning nothing.
> ...

Nonsense. It's the place where you inject assumptions into your 
conditional verifier. It reduces the amount of code you have to audit to 
convince yourself that a given dependency will not corrupt the internal 
state of your program.

>> I think you're getting caught up on the choice of terminology. It's 
>> just a hierarchy of guarantees:
> No, I'm caught up in the semantics. I see that a condition cannot be met 
> and therefore unnecessary.

You are operating on bad assumptions or bad logic. @trusted is clearly 
useful, because it makes no sense to require every piece of trusted code 
to be part of the compiler implementation.

> @trusted is an oxymoron.
@trusted void foo(int[] a,int b){

@system void bar(int[] a,int b){

How do you not see the difference, that it is useful to annotate that 
difference, and that it is okay to call foo from @safe code, but not bar?

More information about the Digitalmars-d mailing list