@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