DIP 1028---Make @safe the Default---Community Review Round 1

[Timon Gehr]

On 08.01.20 08:10, Arine wrote:
> 
> @trusted doesn't really make sense. It is pretty much @system that @safe 
> can call. It's actually kind of bad as how easily it can be misused. 
> @trusted: comes to mind. You can have @trusted destructors. So when you 
> are reading @safe code you can't easily tell where potentially @unsafe 
> code is located. As the @trusted is applied to the function, not at the 
> call site (like Rust/C#).
> ...

This line of reasoning makes no sense.

@trusted void foo(T...)(T args){ ... }

is like

@safe void foo(T...)(T args){ unsafe{ ... } }

It's the same thing. The point is that the interface of foo is assumed 
to safe by all callers even though the implementation might not be.

> If we are going to make @safe the default we don't really need @safe 
> keyword, or @system or @trusted. It's make sense to get rid of all 3 of 
> them and just add @unsafe. If you are going to do it, might as well do 
> it right the first time.

I don't care all that much either way, but let's not pretend that what 
you propose is different to what we have in any important way other than 
how convenient certain things are to express. Adding trusted statement 
blocks and deprecating `@trusted:` annotations would have essentially 
the same effect.