@trust is an encapsulation method, not an escape

David Nadlinger via Digitalmars-d digitalmars-d at puremagic.com
Fri Feb 6 10:58:26 PST 2015


On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic wrote:
> It's been suggested that '@system' be used to mark the blocks 
> in question. The point would be to emphasize the dangerousness 
> of the operation. The function is still @trusted, but inside, 
> the @system code is marked as such.

This is precisely equivalent to just making the function @safe 
and using @trusted blocks inside (which is incidentally my 
preferred approach, and similar to what parts of Phobos try to 
emulate).

As I argued almost three years ago in my "@trusted considered 
harmful" post, @trusted doesn't differ in meaning from @safe for 
API clients. Both mean that you can call the function from @safe 
code, nothing more, nothing less. I hope we agree on that.

You might argue that having @trusted in the function declaration 
serves as an indicator that the implementation requires extra 
careful review. However, there will *still* be a @trusted keyword 
sitting in the source code and staring at your face even with 
@trusted blocks. And if you don't have the source code for a 
function you call to begin with, all bets are off anyway (i.e. 
you need to trust its author) as @safe functions may always 
internally call @trusted ones.

If the leadership feels that your proposal is to be preferred 
because it keeps @trusted in the function signature (as he 
correctly remarked, the safety of @trusted blocks might depend on 
surrounding @safe code), then so be it. However, it makes an 
implementation detail part of the API (see "@trusted considered 
harmful"), and furthermore is not backwards-compatible.

David


More information about the Digitalmars-d mailing list