@trust is an encapsulation method, not an escape

[via Digitalmars-d]

On Friday, 6 February 2015 at 15:10:18 UTC, Steven Schveighoffer 
wrote:
> into suspect the whole function. So marking a function @safe, 
> and having it mean "this function has NO TRUSTED OR SYSTEM CODE 
> in it whatsoever, is probably the right move, regardless of any 
> other changes.

But that would break if you want to call a @safe function with a 
@trusted function reference as a parameter? Or did I 
misunderstand what you meant here?

And... what happens if you bring in a new architecture that 
requires @trusted implementation of a library function that is 
@safe on other architectures?

> 1. A way to say "this function needs extra scrutiny"
> 2. Mechanical verification as MUCH AS POSSIBLE, and especially 
> for changes to said function.
>
> Yes, we can do 2 manually if necessary. But having a compiler 
> that never misses on pointing out certain bad things is so much 
> better than not having it.

I am not sure if it is worth the trouble. If you are gonna 
conduct a semi formal proof, then you should not have a 
mechanical sleeping pillow that makes you sloppy. ;-)

Also if you do safety reviews they should be separate from the 
functional review and only focus on safety.

Maybe it would be interesting to have an annotation for 
@notprovenyet, so that you could have regular reviews during 
development and then scan the source code for @trusted functions 
that need a safety review before you a release is permitted? That 
way you don't have to do the safety review for every single 
mutation of the @trusted function.

>> Maybe it should have been called "@manually_proven_safe" 
>> instead, to
>> discourage use...
>
> @assume_safe would probably be the right moniker since that's 
> what we use elsewhere. But it's water under the bridge now...

Yeah, it was merely the psychological effect that one might 
hestitate to actually type in "I have proven this" without 
thinking twice about it. "I trust this code" is an easy claim... 
;-)