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

[aberba]

On Wednesday, 27 May 2020 at 14:23:30 UTC, Mathias LANG wrote:
> On Wednesday, 27 May 2020 at 12:59:12 UTC, aberba wrote:
>> [...]
>
> 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.

That's what I'm thinking...it seems the interest in taking too 
from rust seems very concerning.

Walter himself has said many times he does not write 
application/library code. My worst fear is engineering gone bad. 
Where technical people build a technology with technical 
judgement only to fail at it because it ends up being too 
difficult to use for everyday code. And that's how I see things.

When its said that MANY people agree that @safe by default is THE 
way to go, I wonder if its based on some few vocal people or its 
an accurate representation of a general interest in direction.


> You will only get opinions, not fact.

That's very concerning. Are the MANY vocal ones using D in system 
code or application, production or hobby? This all shapes ones 
opinion.