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

[jxel]

On Sunday, 5 January 2020 at 04:07:52 UTC, H. S. Teoh wrote:
> On Sat, Jan 04, 2020 at 10:35:19PM +0000, jxel via 
> Digitalmars-d wrote: [...]
>> I looked at a few of the dub packages that work with the safe 
>> transition, some of them just had @trusted: at the top.
> [...]
>
> Yikes. Which packages are those?  Blanket @trusted at the top 
> of a file is a huge anti-pattern, and a big red flag that the 
> code is *not* to be trusted.
>
> Proper use of @trusted dictates that it should be as small and 
> as contained as possible, and that it should only be applied to 
> functions that export a safe API. I.e., this:
>
> 	void trustedMemset(void* buf, size_t sz, ubyte data) @trusted
>
> is flat-out wrong code, because there is no way to ensure that 
> the parameters received by the function are actually safe. The 
> correct signature is:
>
> 	void trustedMemset(void[] buf, ubyte data) @trusted
>
> because the slice ensures that the length will always be 
> consistent with the actual buffer size when passed from @safe 
> code. (Of course, all bets are off if the caller is @system.)
>
> There is no way you can check an entire module this way *and* 
> ensure it continues to obey this rule over time in the face of 
> ongoing code changes. (And that's not to mention the respective 
> function bodies, all of which must be vetted before it can be 
> trusted.) I absolutely do not trust any module that has 
> @trusted: at the top.
>
>
> T

Well you can call @safe code from @system, so you can't really 
guarantee the value is correct in @safe. Kind of the same 
situation with an uninitialized bool that evaluates differently 
because of the code gen. The only way to guarantee it is valid is 
if you created the variable in @safe and wasn't passed as a 
parameter.

Anyways, realistically people are just going to use @trusted: 
more instead of @system: because @trusted: is an actual solution 
and doesn't require fixing templates and any other anomalies that 
show up. So yes more code will work with @safe but it won't 
actually make it safer.