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

[Mathias LANG]

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.

You will only get opinions, not fact. So here's mine: It depends.

It depends on the kind of code you are writing. Could you write 
your code in Python / C# just as likely ? Then yes, it is 
probably a good thing for you.

Now, are you writing code that needs to be careful about 
allocation, and needs to have low latency / high performance ? 
You're likely to have a bunch of un-`@safe` tricks all over the 
place, to bypass bounds checking, make the code easier to 
optimize, or avoid branches. Walter himself rejected a change 
that would have made code `@safe` because it would also make it 
slower 
(https://github.com/dlang/dmd/pull/10940#issuecomment-600894940).

But not everyone is in this craft, either. Maybe you just want to 
write a library for people to use ? Well I got a bad news for 
you: Composing attributes doesn't work well with OOP or delegates 
(contravariance for delegate is not implemented, nor is it 
possible to tie a function's attributes to its delegate 
parameter). So you end up having to choose: Does your callback / 
interface expose a `@safe` / `nothrow` / `@nogc` / `pure` 
interface, or not ? If it does, you either need to **force** the 
caller to use `@safe` & co as well, or need to template 
everything, rendering the use of OOP useless.

And the same issues with OOP / delegate affect application code, 
of course, but add to that the fact that most libraries out there 
had to choose a set of attributes, and you are locked in a weird 
place.

Next issue: if you want to quickly experiment / prototype, 
`@safe` by default is likely to get in your way. So you'll end up 
putting `@system` or `@trusted` everywhere just to satisfy the 
compiler. Even if you are conscious and **try** to put `@system`, 
remember that libraries will have to make a choice (and that 
choice will be `@safe`), so yeah, you're going to greenwash to be 
able to provide callbacks.

And obviously, there's the case of people just copy-pasting their 
C[++] prototype in their module to get things working and then 
not wanting to deal with the issue of making things correct.

As you can guess, while I said that "It depends", I am personally 
in the library author / prototyping / low level code category and 
I think it's a terrible choice. And as someone who has a decent 
professional and personal investment in the language, I also 
think it goes against almost everything that makes me, and I 
believe many other people, choose the language:
- ~Great~ Amazing integration with C / C++;
- Easy prototyping yet almost production-ready code;
- A language that doesn't get in your way, where you pay as you 
go;

All of the above would be compromised by making `@safe` the 
default, *especially* in the way DIP1028 plans it. If `@safe` 
didn't get in the way, I would be much more inclined to cheer for 
it.