@trust is an encapsulation method, not an escape
Zach the Mystic via Digitalmars-d
digitalmars-d at puremagic.com
Fri Feb 6 15:02:53 PST 2015
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/eeglnychgudcffpjcdvy@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!
More information about the Digitalmars-d
mailing list