@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