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

[Dominikus Dittes Scherkl]

On Thursday, 2 January 2020 at 14:43:50 UTC, ag0aep6g wrote:
> On 02.01.20 14:47, Dominikus Dittes Scherkl wrote:
>> But at the same time, additionally @trusted as a function 
>> attribute should be removed and replaced by @trusted 
>> expressions. Because:
> [...]
>> @trusted should be restricted to as few code as possible, at 
>> best only to the line of code where it is really necessary to 
>> make a function @safe.
>
> One step at a time. As it is, the DIP may be disruptive but 
> it's simple. Improvements to @trusted can go in another DIP.
But it is also simple (you just don't need the two pairs of 
parents at the start and the end of a @trusted lambda anymore) 
and it affects pretty much exactly the same places as this DIP. 
The deprecation period will be rather long, so I think it would 
be a good idea to do both in one wash.

>
> Applying @trusted to as little code as possible sounds good, 
> but it's often done incorrectly
That won't change. You still need to trust things marked as 
@trusted
(or better: check them again!). This will only be easier if less 
code is marked such.

> For a caller, there is zero difference between these two 
> functions:
>
>     void f() @trusted { /* ... stuff ... */ }
>     void f() @safe { () @trusted { /* ... the same stuff ... */ 
> } (); }
>
> Having @trusted visible in the function signature just gives 
> people wrong ideas about what it means.
Exactly. That's why forbidding @trusted at function level is a 
gain.
You loose nothing (you can always replace all trusted functions 
in the way you illustrated here), but you can improve code a lot.
And you avoid that plenty of new trusted functions suddenly pop 
up, with no resources to check if they are really @safe or why 
exactly they are not.