May 24, 2022

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

>

I think this is better

 // debug assertion
 assert(condition);

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

or also

 // debug assertion
 assert(condition);

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

so when your program fails the final user is aware of what went wrong.

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.

May 25, 2022

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

>

On Tuesday, 24 May 2022 at 12:51:32 UTC, Siarhei Siamashka wrote:

>

Please educate yourself about the @safe attribute.

Please refrain from uninformed personal attacks.

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.

>

You might notice I said "default safety features". Here's the facts.

D's default: significant safety by default,

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.

>

Where it is necessary to bypass these important checks, which btw is a small minority of places, you can use .ptr locally, after verifying correctness, to disable it selectively while keeping safety by default.

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.

>

By contrast, once you choose to use -release, you get security holes by default, which is the opposite of what you want when actually releasing code to real users! You can then opt back into minimum safety checks (which you want in a vast majority of places) on a case-by-case basis by adding @safe

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.

>

The compiler is likely to fight you throughout this process as
other library authors must also remember to opt into it.

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.

>

A programming language ought to align with safety and common use. -release does the opposite of this, with very little warning.

See above. We just have a major disagreement here.

>

Never using it, on the other hand, aligns with these virtues, while still letting you very conveniently bypass checks when it is genuinely necessary and beneficial.

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

May 25, 2022
On Sunday, 22 May 2022 at 22:59:25 UTC, Walter Bright wrote:

>
> This is a faulty system design. There's nothing stopping modules from corrupting the memory of the caller.

It is not as much a faulty design as it is a trade off. Some systems cannot afford IPC.  Consider Linux kernel "oops" failures, which may leave the system in an unstable state without tearing it down completely.

> The correct approach is to run those modules as separate processes, where they can only corrupt themselves.

Or .NET application domains (WebAssembly modules, etc) running in the same process.

> It's why operating systems support processes and interprocess communications.

I know how operating systems work. BTW, the entire monolithic vs microkernel debate is about this.
May 25, 2022

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

>

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

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.

May 25, 2022

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

>

We should not have release switch as it is now due to those security holes mentioned.

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.

May 25, 2022

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

>

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

>

We should not have release switch as it is now due to those security holes mentioned.

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.

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.

>

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?

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.

>

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.

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.

May 25, 2022

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

>

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

>

We should not have release switch as it is now due to those security holes mentioned.

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.

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.

>

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.

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.

May 25, 2022
On 5/23/2022 8:43 PM, max haughton wrote:
> On Tuesday, 24 May 2022 at 02:05:39 UTC, Walter Bright wrote:
>> On 5/23/2022 7:07 AM, deadalnix wrote:
>>> C asserts are included or not based on various defines.
>>
>> Building them in offers some semantic advantages,
>>
>> 1. being able to get them to do things line insert a HLT instruction
>> 2. format an error message based on stringizing the expression
>> 3. people won't be motivated to create their own
> 
> Another reason is that forcing people down a blessed road means that the means you provide for fiddling with behaviour can be composed together much more easily (whether this be some runtime hook or merely all Assertions throwing the same Error).
> 
> 

A user can still write their own myAssert(). But by building it in and making it so convenient, this just doesn't happen. It's also why `debug` is builtin - managers had complained to me that they could never get C++ code written by different teams to work together because they each developed their own `debug` conventions.
May 25, 2022
On 5/24/2022 4:26 AM, Adam D Ruppe wrote:
> It is a terrible switch that does random bad things.

Back in the olden daze, I've seen magazine compiler benchmark articles trash various compilers for poor runtime performance. It nearly always boiled down to the journalist not using the right switches for release builds.

So I'm leery of not being able to turn off the runtime checks to get max performance.

Besides, it provides a way of accurately measuring how much the runtime checks are costing.
May 25, 2022
On Wed, May 25, 2022 at 11:56:03AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/24/2022 4:26 AM, Adam D Ruppe wrote:
> > It is a terrible switch that does random bad things.
> 
> Back in the olden daze, I've seen magazine compiler benchmark articles trash various compilers for poor runtime performance. It nearly always boiled down to the journalist not using the right switches for release builds.
> 
> So I'm leery of not being able to turn off the runtime checks to get max performance.

Unfortunately, we're not living in the olden daze anymore.  We're living in days of widespread exploitation of out-of-bounds memory accesses, buffer overflows, and other such things by malicious entities.  These days, what the internet equivalent of magazines trash is no longer poor raw performance, but the lack of security features that prevent these sorts of exploits.

Slices and @safe were the right direction towards the future; -release disabling all bounds checks is regressing towards bygone days that are better left forgotten.  Unfortunately, -release negates much of the benefits the former gives us.


> Besides, it provides a way of accurately measuring how much the runtime checks are costing.

I wouldn't be against an explicit switch to disable bounds checks for when you want to measure this.  But it should not be the default behaviour of -release. It should be called -disable-all-checks or something along those lines.  In this day and age, nobody should release software without bounds checks anymore.  We're no longer living in the 70's.  Just browse through the latest CVEs and see how frequently the lack of bounds checks in C/C++ leads to all sorts of recurring security holes and exploits.  Plugging those holes matter far more than the bragging rights of "winning" some petty benchmarks.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton