Optional safety is really outdated, I think some people can't see how important is safety almost everywhere (both for system and general purpose). Safe by default allows you to catch bugs without possibly wrecking your entire system (or systems' of users of your app).
Some people are defending "Just don't make mistake" but we are all human and make mistakes, even experienced progammers can easily make mistakes, it's normal. So I think @safe should be default in dlang.

Advantages:
Not being scared to code - unsafe languages makes you scared to code (I experienced this the hard way) you usually never use the language's power at %100, because if you make mistake it can easily get you in trouble.
In @safe code, making mistakes and learning from them is easier.

Less security vulnerabilities - Mistakes throw helpful exception and halts program instead of causing security issues.

Also some myths about @safe:
"It's slow and uses a lot memory" - It is true that safe can be slower than unsafe and use more memory, but performance is not the only thing a language can offer. I am asking, did you ever hit %100 CPU usage or ran out of memory, yet still needed more performance or storage (ram), if it's the case I recommend you to first optimize code before switching to unsafe.

"It's protects agaisnt all security vulnerabilities" - It is true @safe can prevent some security issues, but not all of them, remember to never trust user input.

On Tuesday, 26 December 2023 at 07:05:48 UTC, Hors wrote:

Yes, safety should be the default. Unfortunately, making it so would be a big breaking change. We're going to look into doing it once we get going with editions.

https://dlang.org/spec/function.html#safe-functions

-No casting from a pointer type to any type with pointers other than void*.
-No casting from any non-pointer type to a pointer type.
-No pointer arithmetic (including pointer indexing).
-Cannot access __gshared variables.
-No inline assembler.

I hope this never becomes the default

On Tuesday, 26 December 2023 at 11:32:15 UTC, ryuukk_ wrote:

I very much hope it does. It is a lot more economical.

9 out of 10 projects only need the features you mentioned sparingly. It is less effort to mark those place @trusted than the situation we are in now, where you need to sprinkle @safe almost everywhere.

Another way to look at is that the features you mentioned are almost always used exclusively in low level code that best sits behind an abstraction. If trusted is the default you need to mark anything using it @safe, but if safe is the default you only need to mark a few reusable low level pieces of code @trusted.

On Tuesday, 26 December 2023 at 07:05:48 UTC, Hors wrote:

So does most everybody else, including library authors who would be primarily affected by the potentially breaking change.

See this from the author of vibe, dated March 15, 2015: http://arsdnet.net/this-week-in-d/mar-15.html

Or this from the author of arsd, dated April 17, 2016:
http://arsdnet.net/this-week-in-d/2016-apr-17.html

Or this from the author of dmd, dated January 2, 2020:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md

On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe wrote:

The earlier proposal would have killed D. I no longer recall the details but it would have been miserable to interoperate with C code under that proposal. And without C interoperability, D is dead.

All that's needed is a compiler switch rather than breaking everyone's code. Or an easy way to shut it off. Neither of those were on the table.

On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

Makes sense, instead of a breaking change. We can use another file extension for Safe DLang *.safeD, or [insert your idea here]. That file extension is just D but @safe is default, then it's no longer a breaking change as normal *.d codes still work.

On Tuesday, 26 December 2023 at 12:39:46 UTC, bachmeier wrote:

Rust, Go, Swift, C# are doing just fine with the requirement that C interop must be explicitly marked as unsafe.

On Tuesday, 26 December 2023 at 08:10:51 UTC, Mike Parker wrote:

Instead of trying to pry safe by default in current D, D should be revised totally from the ground up and design the language to be safe by default from the very beginning. We're talking about D3 or a fork here.

D is starting to show its age and it wasn't designed for "safe" as we know it today. Even if implemented in D, there would be holes in the design where unsafe can sneak in.