@trust is an encapsulation method, not an escape

[Paulo Pinto via Digitalmars-d]

On Friday, 6 February 2015 at 15:14:14 UTC, Wyatt wrote:
> On Friday, 6 February 2015 at 13:42:40 UTC, Ola Fosheim Grøstad 
> wrote:
>>
>> "cannot modify this without detailed review".
>>
> This quote from Ola, here?  That basically describes my job 
> maintaining big piles of legacy C: the compiler verifies 
> nothing, so every change to the anything in the API of "safe" 
> functions or anything in their entire call chain must be 
> painstakingly reviewed.
>
> A single change generally takes me several days of research, 
> verification, and testing.  I fixed about 150 potential memory 
> issues (and several really dumb logic errors) with Clang's 
> static analysis when I first inherited the code; it took weeks.
>  (And now writing new stuff using this "safe" API is turning up 
> memory safety issues anyway!)
>
> So from my perspective, calling this situation "completely 
> impractical" reveals a stunning gift for understatement.  Is 
> this really the best we can do after however many years?  
> Because it blows.
>
> The current @trusted semantics (and accompanying politics) make 
> it exceedingly clear that @safe is meaningless for anything 
> beyond trivial, one-off tools that will never receive 
> maintenance.
>
> -Wyatt

Exactly the reason why I never liked C and C++ only makes it 
better if everyone on team stays away from Cisms and uses the 
safer alternatives.

Now the C and C++ world finally accepted the use of static 
analyzers, but I had the displeasure to try to find pointer 
related issues without one, back in the .com days. As you say, it 
takes weeks.

Regarding D, maybe @trusted should go away and only keep @system 
(== unsafe in other languages), as it can hardly give any extra 
security guarantee.

However, I don't see how to solve the human review process, as 
that is an halting problem.

--
Paulo