@trusted attribute should be replaced with @trusted blocks

[Timon Gehr]

On 16.01.20 01:09, IGotD- wrote:
> On Wednesday, 15 January 2020 at 23:46:11 UTC, ag0aep6g wrote:
>> You're saying that it is useful for me as a user of Phobos when I see 
>> that, for example, std.stdio.File.open is @trusted [1], right?
>>
> 
> Speaking of libraries, as you can see many calls will go the C library 
> which is of course is unsafe code. The only way I can see it is that 
> @safe code should be able to call unsafe code by default, for convenience.
> ...

That's nonsense, it completely undermines @safe, because many sensible 
@system functions do not have a safe interface. @safe code shouldn't be 
able to directly call `free` from the C standard library on arbitrary 
pointers.

> Now there is a possibility that the programmer wants that the code shall 
> not call any unsafe code what so ever.

@trusted functions are not unsafe, it's just not checked by the compiler.

> Then I think that a function 
> attribute should be added that tells that the code is not allowed to 
> call any unsafe code down the line. This is better because.
> 
> 1. It is a restriction set by the programmer and not some arbitrary 
> promise from a third party.

It's an arbitrary promise from the compiler implementation...

> 2. It is absolute. The compiler can check this, either it hits unsafe or 
> it doesn't. It is either true or false and it cannot be questioned.
> 

This is not better. Why do you trust compilers and standard library 
behave according to the specification but are unwilling to do that for 
any other code that cannot be verified by the compiler? You are making 
an arbitrary distinction where there is none.

The point of @safe is that if you write @safe code (and no @trusted 
code), memory corruption is not supposed to occur; any memory corruption 
that occurs anyway is not your own fault. (Except maybe for not doing 
due diligence when evaluating a potential dependency before using it.)