@trust is an encapsulation method, not an escape

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Mon Feb 9 09:39:52 PST 2015


On 2/6/15 4:48 PM, Walter Bright wrote:
> On 2/6/2015 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
>> This is precisely why I have lost all interest in @safe. It's clear that
>> the present problematic situation will continue to hold, and the
>> decision makers are not interested to address it. I am not going to
>> waste any more time and energy on this topic.
>
> In this thread at 8:20PM last night, Dicebot asked me:
>
> "I am not even sure how you can show the example though, to be honest -
> implied
> issues are about maintaining code and not just writing it."
>
> And I replied with a specific example of how to fix one aspect of
> std.array. There have been no replies. What else can I do to address it?
>

In the case you bring up, maintenance is easy -- the code is incorrect, 
it needs to be fixed/rewritten. No solution ever implemented or proposed 
can stop this from happening.

The case being discussed by Dicebot, and most of us, involves a case 
where an entire @trusted function is PROPERLY implemented, yet someone 
adds incorrect code to it. The compiler does not complain.

Note that if the requested solution was implemented, each of these calls 
should be individual cases to inspect. I don't think anyone disagrees 
that uninitializedArray shouldn't be a public @trusted function. But 
individual cases of it CAN be properly safe.

-Steve


More information about the Digitalmars-d mailing list