On Friday, 6 February 2015 at 21:56:40 UTC, Walter Bright wrote:
On 2/6/2015 11:29 AM, Zach the Mystic wrote:
My attitude is not based on evidence. It's based on just
thinking about the
problem:
http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org
I really can't answer this question.
You asked:
"Why not force the programmer to tag precisely those portions
of his code
which cause him to tag his function @trusted to begin with?"
That question has been asked and answered repeatedly. The
answer is that @trusted is not only to TAG unsafe code, but
must provide a SAFE INTERFACE to it.
@trusted {
... unsafe code ...
}
provides no indication of what the interface to the unsafe code
is. Addressing only the TAG aspect is insufficient.
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks. We
are no longer requesting them. We are requesting *@system*
blocks, which can only appear in @trusted and @system functions.
Any unsafe code appearing in a @trusted function which is not
inside a @system block is an error. We've changed the name, but I
think it will make a world of difference regarding how you will
look at it. Marking '@system' code inside a @trusted function is
exactly what is requested. Your message about '@trusted' being
only acceptable as an interface has been heard. There will be no
@trusted blocks, only @system blocks, which are the exact same
thing, except they can only appear in @trusted and @system
functions.
This solution appeals to me greatly. It pinpoints precisely where
unsafe code can generate; it catches unintended safety violations
in all @trusted code outside @system blocks, as requested by many
people so far; it makes systems programming highly visible, with
redundancy at the function signature and at the unsafe code
itself. I really think it's spot on!
