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

[Arine]

On Wednesday, 8 January 2020 at 18:59:38 UTC, Timon Gehr wrote:
> 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.

That'd be a code smell. If you have to put the entire body of a 
function in unsafe, that function should just be defined as 
unsafe. You've just given the perfect illustration of why 
@trusted is terrible.

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

Did you miss the example?