On Tuesday, 24 May 2022 at 12:51:14 UTC, Loara wrote:

 // debug assertion
 assert(condition);

 // release assertion
 if (!condition) throw new AssertError();

 // debug assertion
 assert(condition);

 // release assertion
 if (!condition) throw new MyCustomError("My error message");

I left off messages for the sake of the example, but of course you should use them in real code.

IMO it is better to use the assert keyword than to throw an Error, so that you can use the -checkaction switch to choose what happens at runtime when an assertion fails.

On Tuesday, 24 May 2022 at 13:43:07 UTC, Adam D Ruppe wrote:

Says the guy who proclaimed "I don't care about @safe". Please understand that we are just not on the same page until you have a sufficient understanding about the @safe attribute, the reasons why it exists and its interaction with the '-release' command line option. That's why I asked you to check it up.

Do you mean that @system code with bounds checking enabled provides "significant safety"? I don't think that this is enough, but this is just my opinion and you are always free to disagree. I think that the other programming languages are setting the bar much higher than that.

There are multiple problem with this approach. The most severe of them is that the ".ptr" construct does not provide bounds checking in debug builds. Convenience is a major factor too, and despite your claims I don't agree that ".ptr" is convenient. I personally don't see any reasons to use it.

Did you even read my replies? You got everything backwards. I'm in favor of having everything @safe by default and then opt out on a case-by-case basis by adding @trusted where necessary. This works very nicely with the current '-release' option. Whoever implemented it this way did a great job!

I remind you that there's no obligation for us to agree. And no, having a different opinion is not a personal attack.

Yes, not all libraries are fully compatible with @safe and this is probably something that could be improved. Thankfully my use cases don't depend on the other libraries at the moment.

See above. We just have a major disagreement here.

Your standards of what is "convenient" are obviously very different from mine.

On Wednesday, 25 May 2022 at 08:34:49 UTC, Siarhei Siamashka wrote:

Asking someone to educate himself implying that the person doesn't know anything, can be treated as an attack, though.

We should not have release switch as it is now due to those security holes mentioned. Probably the best thing would be is to not turn off some of security features such as bounds checking in release mode. I.e. keep optimizations enabled, as well as security checks that are expected to be beneficial even in release binaries.

On Wednesday, 25 May 2022 at 13:34:35 UTC, Alexandru Ermicioi wrote:

That's merely the Adam's claim. He is trying to very aggressively "save" me from some non-existing problems without realizing that I'm just not using D language in the same way as he does. He is too busy being engaged in some sort of shadowboxing against himself and is not paying attention to my explanations.

To sum it up. The '-release' switch doesn't disable bounds checking in @safe parts of the code. So we are fine as long as the majority of code in a project is marked as @safe. Rather than removing or changing the '-release' switch, I think that a much better idea is to migrate more code and libraries to @safe and my understanding is that D language is moving in that direction. Maybe Walter can confirm or deny this?

Regarding the name of this topic. If the '-release' switch removal idea gains traction, it will be a strong reason for me to quit. Performance parity with C++ without unreasonable extra efforts is very high on my priority list. If extra efforts are unavoidable and D loses its rapid development appeal, then there's always Rust as a more mainstream alternative.

On Wednesday, 25 May 2022 at 16:17:06 UTC, Siarhei Siamashka wrote:

Adam has "saved" many dlang programmers with his pragmatic and real-world-safety oriented advice. He is the most prolific, and one of the most respected, dlang contributors in the discord threads. His book, https://www.amazon.com/D-Cookbook-Adam-D-Ruppe/dp/1783287217 , was one of the sources I referenced when onboarding. His library work, https://github.com/adamdruppe/arsd , is very well regarded.

D gives you a lot of options wrt @safe ty. My personal preference, probably shared by some others, is that the defaults should favor correctness and convenience with all else being opt-in.

I'm quite concerned with ultimate performance (real time video processing) and yet have found it easy to employ D in a very safe/convenient form for almost all my code (@safe, immutable/const, pure, gc, throw) while using dcompute, __vector, @trusted, .ptr and the like when I need to be on the metal.

The -release switch activates a combination of finer grain controls. You can put together whatever combination you wish in your build scripts. I don't know how a command line fixable inconvenience compares to those that you'd experience if you decamp to the Rust world but if you do I'd like to hear your take on it.

On Wednesday, 25 May 2022 at 16:17:06 UTC, Siarhei Siamashka wrote:

Nah, not just Adam's. There are other people that also complained at disabled bounds checking in release mode as well as disabled contracts. So the opinion for release mode now leans towards more safety even for system code.

I do agree that it should not be removed, but I'm for a change in what this switch turns on and off (more safety even for system code). It is quite nice switch for turning all default recommendations, without the need to scurry over all dmd options to find which should be for release turned on. That's actually what I really hated in c++ compilers as well as make files. So many options, words, magic, even for simple projects, for newbies that it just blows your mind, and just end up with a copy pasted make file from somewhere, in order to start coding.