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

[Timon Gehr]

On 09.01.20 07:19, Arine wrote:
> 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.

Nonsense. If a function provides a safe interface, @safe code should be 
able to call it freely. Forcing client code to unnecessarily sprinkle 
unsafe blocks everywhere is a bad idea.

> You've just given the perfect illustration of why @trusted is terrible.
> ...

Not really, but it appears you might not properly understand either 
@safe/@trusted/@system or @safe/@unsafe or modular software 
verification. The main drawback of @unsafe is that its meaning on blocks 
is dual to its meaning on functions. Unsafe blocks are like @trusted 
(trust me, what's in this block is fine) and @unsafe functions are like 
@system (be careful, the compiler will not check all preconditions 
required to call this function safely). The only benefit of 
@safe/@unsafe is that you need fewer keywords. It's actually more confusing.

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

Of course not. Your example is either terrible or covered by trusted 
statement blocks. Not sure which.