Non-techincal brain, is @safe by default good or not?

[Paul Backus]

On Wednesday, 27 May 2020 at 12:59:12 UTC, aberba wrote:
> So I'm trying to wrap my head around the DIP 1028 thing here. 
> I'm aware @live was introduced to give us rust-like safety. 
> That seemed cool as long as it was purely opt-in.
>
> Now I hearing @safe by default which reads like the plan has 
> changed and now the direction is going all-in on everything 
> MUST BE SAFE. After reading the DIP, I getting a feeling I'll 
> need to re-think my programming model to make everything safe. 
> Sound in my understanding like most code will break. 
> Communist/Socialist kind of coding.
>
> Aside issues with how leadership manage communication and 
> stuff, is this move, as I understand it, good or not? (both 
> practical everyday use and existing code bases). I'm not 
> getting what feedback kicked off this move to @safe by default.
>
> Please help me understand.

@safe by default is good because it encourages code that already 
*is* @safe to be *treated* as @safe.

Currently, a lot of D code is written that could be @safe, but 
isn't, because the programmer can't be bothered to actually mark 
it with the @safe attribute. When @safe is made the default, this 
won't be a problem. If you write @safe code, the compiler will 
treat it as @safe, without you having to put in any extra effort. 
Almost everybody agrees that this is a good thing.

The problem with DIP 1028 is that it also applies 
@safe-by-default to external function declarations, including 
extern(C) functions like `printf` and `memcpy` that absolutely 
*shouldn't* be treated as @safe. Many, many people, including 
Andrei Alexandrescu, who used to be one of the Language 
Maintainers, have been trying to explain to Walter why this is a 
problem. So far, he remains unconvinced.