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

[jxel]

On Sunday, 5 January 2020 at 17:57:18 UTC, H. S. Teoh wrote:
> On Sun, Jan 05, 2020 at 04:43:55PM +0000, jxel via 
> Digitalmars-d wrote: [...]
>> Well you can call @safe code from @system, so you can't really 
>> guarantee the value is correct in @safe.
>
> The guarantees of @safe is conditioned upon being called from 
> other @safe code. As long as somewhere at the top of the call 
> chain there's a @system function, then all bets are off.  This 
> is why this DIP is so important: until main() can become @safe, 
> there's always a possibility that somewhere along the line you 
> screwed up and negated the guarantees of @safe. This is 
> unavoidable; for example a @system main() could have trashed 
> the entire RAM before calling a @safe function, and it's 
> already in UB land when the @safe function runs, so there's no 
> way for the @safe function to guarantee anything.
>
> Our current situation is that we have @system on top of the 
> call chain (because not everything is @safe yet) and maybe some 
> @safe bits lower down or at the bottom.  Where we want to get 
> to is @safe at the top, and small bits of @system at the bottom 
> gated by properly-audited @trusted entry points.  This DIP is 
> an important step in this direction.

What if you have a @safe library that gets called from another 
program that is @system. You can't guarantee anything. If safety 
matters to you then use it. Its not going to stop bad code. If 
someone gets an error and inserting @trusted gets it to compile, 
or they can spend 2-4 hours restructuring code, they are going to 
use the option that doesn't waste their time.

>> 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.
>
> D always initializes all locals. Writing `bool b = void;' is 
> @system, so again, once your caller is @system, all bets are 
> off further down the call chain.


Bzz, wrong. You can void initialize in @safe.


>> 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.
>
> If I had my way, I'd outright outlaw "@trusted:" and only allow 
> it on smaller constructs.  If you really wanted to trust an 
> entire module that's essentially @system, just write main() 
> @system and be done with it. Why lie to yourself for no benefit 
> whatsoever?
>
>
> T

If its safe by default, throwing @system: at the top won't work 
for everything. It'll stop template auto inferring, so @trusted 
is the only real simple solution. If you are using @system, it 
doesn't matter to you cause you don't get that safety anyways. 
Its a matter of getting your code to compile again, @trusted is 
going to be the quickest easiest solution.