Fantastic exchange from DConf

[Dominikus Dittes Scherkl via Digitalmars-d]

On Friday, 19 May 2017 at 15:52:52 UTC, Moritz Maxeiner wrote:
> On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer
>> I don't expect people to use Phobos and audit all the @trusted 
>> blocks personally.
>
> As long as they don't actually call them, that's reasonable. 
> But if your application ends up calling @trusted code and you 
> did not audit that @trusted yourself, you have violated the 
> @trusted requirement:
> You cannot promise to the compiler that the code is memory safe 
> since you have no knowledge of what it actually does.
No. @trusted is about trust: you cannot rely on the compiler to 
verify it, but the code is reviewed by humans. So there is a list 
of reviewers and if this list contains some names you happen to 
trust (sic!) you don't have to audit the code yourself.
Especially basic libraries will over time become tested and 
audited by very many people or even organizations. So after some 
time they really can be trusted.

>> If "D is  memory safe" means "D is memory safe ONLY if you 
>> verify all of the standard library personally", we still have 
>> lost.
>
> It is more like "D is memory safe" meaning "D is memory safe 
> ONLY if you verify all of the @trusted code your application 
> end up compiling in / linking against".
> There is no way around that I can see without getting rid of 
> @trusted, which is impossible for a systems PL.
For bigger projects you always need to trust in some previous 
work. But having the @trusted and @save mechanism makes the 
resulting code a whole lot more trustworthy than any C library 
can ever be - just by reducing the number of lines of code that 
really need be audited.
I personally would not going bejond probing some few functions 
within a library which I think are more complicated and fragile, 
and if I find them ok, my trust in what else the authors have 
marked @trusted increases likewise.