On Tuesday, 24 May 2022 at 06:55:52 UTC, Siarhei Siamashka wrote:
> 
> ....
> You just need to remember to use 'enforce' instead of 'assert'. ....

It's not correct to suggest that these are simply interchangeable.

They may appear to be similar, but they are two very different things.

For example (to just make that point):

nothrow void checkSomething(bool checkThis)
{
    //enforce(checkThis == true); // nope! enforce throws an exception.
    assert(checkThis == true); // ok.
}

On Tuesday, 24 May 2022 at 06:12:40 UTC, forkit wrote:
> Then, in order to leave my assert's in production code, I need to 'remember' not to compile with -release, but rather -someothercrap I can't remember at the moment.

Never ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever use -release.

It should be removed, or at least renamed to -add-random-security-holes-for-zero-benefit.

It is a terrible switch that does random bad things.

On Tuesday, 24 May 2022 at 09:05:57 UTC, Siarhei Siamashka wrote:
> So having the '-release' option, which provides reasonable and mostly optimal defaults is very useful.

It is neither reasonable nor optimal. -release enables a random set of *bad* switches that will HURT your code. It removes all the default safety features in the language for no actual benefit!

Seriously, *never* use it. It should be removed.


If you want optimization, -release doesn't do this. -O does.

On Tuesday, 24 May 2022 at 12:10:36 UTC, Siarhei Siamashka wrote:
> One of the valid criticisms of D language is that it is not @safe by default.

I don't care about @safe. I'm talking real world safety, things like automatic bounds checks.

> Right now the '-release' option disables bounds checking in @system code and this is a **necessary** escape hatch to keep D language competitive with C++ and the other system programming languages.

False. You can put `.ptr` in strategic places to disable it locally instead of bludgeoning it with a superglobal switch.

Even if you want to disable it globally (and you don't, unless you're too incompetent to be allowed to release anything to the public), there's the -boundscheck=off switch for that. Bundling it with a bunch of other things and hiding it behind a harmless-sounding "-release" thing is criminally negligent in a sane world.

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.

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

D's default: significant safety *by default*, eliminating over 90% of C-specific bugs (which btw are a minority of actual bugs; it is important to remember to keep it in perspective). 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.

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` (...until some poor user is told to use -boundscheck=off but that's on them, at least that switch sounds like you should think twice, unlike -release which sounds harmless while being anything but). The compiler is likely to fight you throughout this process as other library authors must also remember to opt into it.


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

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.