@trust is an encapsulation method, not an escape

[Walter Bright via Digitalmars-d]

On 2/6/2015 3:34 PM, David Nadlinger wrote:
> On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
>> I suspect that such a feature would simply lull people into a false sense of
>> security in that merely tagging an unsafe cast with @system and the compiler
>> accepting it is good enough.
>>
>> My evidence for this is how @trusted was used in Phobos.
>
> How is adding @system to some operations *in addition to* adding @trusted to the
> function declaration more likely to lull people into a false sense of security
> than just adding @trusted right now?
>
> Let me also point out that the cases where the @system block equivalent is used
> right now (like in std.file, or the trustedXyz functions in std.array) are NOT
> the ones that actually have safety bugs in them (such as
> std.array.uninitializedArray or std.uuid.randomUUID). The two latter examples
> were actually written in your preferred style.

I've said that the usage of those functions was not actually buggy, what was 
wrong about them was that they required review of the surrounding supposedly 
safe context. I.e. they produced a false sense of safety. I fear the @system 
blocks, even if only allowed in @trusted functions, would produce a similar 
illusion of safety.

I agree with Andrei in that I do not believe that reviewing a @trusted function, 
line by line, for safety is necessarily some sort of maintenance nightmare. If 
it is, then a refactoring should be considered to encapsulate the unsafe code in 
a smaller, simpler manner.

I.e. let's make an effort to use @trusted correctly, and then see where we stand.

Scott Meyer's excellent article (a classic):

   http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

describes this most eloquently. (Just substitute "private members" with "trusted 
code".)