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".)

Reply via email to