@trust is an encapsulation method, not an escape

Zach the Mystic via Digitalmars-d digitalmars-d at puremagic.com
Sat Feb 7 04:34:35 PST 2015


On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
> On 2/6/2015 3:02 PM, Zach the Mystic wrote:
>> 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!
>
> 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.

I'm also not saying phobos was written perfectly to begin with. I 
think that this whole @system blocks suggestion came up in a 
slightly different context than did your original discontent with 
std.file and std.array. I'm not sure you're ever going to stop 
careless programmers from getting their bad code to compile. But 
I think that's a different issue from giving good, careful 
programmers the tools they need. Right now, @trusted functions 
are the only tool they have to help people figure out where the 
unsafe code is, but it's not enough. Nested @trusted functions, 
and @trusted lambas are clearly being added as a workaround for 
not being able to "un at trust" large portions of code intended to 
be @safe.


More information about the Digitalmars-d mailing list