@trust is an encapsulation method, not an escape

[Zach the Mystic via Digitalmars-d]

On Friday, 6 February 2015 at 18:58:27 UTC, David Nadlinger wrote:
> 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).

No it's not. Forcing @trusted functions, with @system blocks 
inside builds a redundancy into the system. Now someone from 
outside the can read the signature and know there might be a 
problem, and someone inside can find everywhere that problem 
could possibly have arisen from. The difference is you now have 
two signals instead of one - one in the function header, and the 
other(s) in the code itself.

> 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.

I know. This was recently pointed out again by Steven 
Schveighoffer, and it's a great insight.

> 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.

It is a redundancy, yes, but one people might actually 
*appreciate*. People around here take memory safety very 
seriously, and probably with good reason!

> 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.

It's not backward-compatible, but it's not hard to fix at all. 
You get an error, and you enclose your unsafe code in a @system 
block. And the quality of your code improves at the same time.

The only reason the implementation detail, @trusted, was made 
part of the API was precisely because memory safety is taken 
extremely seriously by the language designers. There's no other 
reason I can think of, but for some reason, I can appreciate the 
thought. Also, I want to find a real solution and I doubt anyone 
is suggesting getting rid of @trusted at this point.