On Saturday, 13 July 2024 at 16:48:29 UTC, Walter Bright wrote:
> On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:
>> It's equivalent to `-check=invariant=off -check=in=off -check=out=off -check=bounds=safeonly -check=assert=off -check=switch=off` (and what Nicholas pointed out).
>> 
>> `-O` and `-inline` are orthogonal to `-release` (and to each other).
>
>
> Hmm, checking the actual implementation, you're right. Someone must have changed it at some point. -release is supposed to be "fastest code". Need to fix that!

I honestly don't really care if -release exists or does the right thing, as long as

dub -b release-nobounds gives me the (reasonably) fastest possible thing

On 15/07/2024 3:36 AM, Guillaume Piolat wrote:
> On Saturday, 13 July 2024 at 16:48:29 UTC, Walter Bright wrote:
>> On 7/13/2024 8:28 AM, Vladimir Panteleev wrote:
>>> It's equivalent to `-check=invariant=off -check=in=off -check=out=off -check=bounds=safeonly -check=assert=off -check=switch=off` (and what Nicholas pointed out).
>>>
>>> `-O` and `-inline` are orthogonal to `-release` (and to each other).
>>
>>
>> Hmm, checking the actual implementation, you're right. Someone must have changed it at some point. -release is supposed to be "fastest code". Need to fix that!
> 
> I honestly don't really care if -release exists or does the right thing, as long as
> 
> dub -b release-nobounds gives me the (reasonably) fastest possible thing

For reference:

https://dub.pm/dub-reference/buildtypes/

```js
        "release": {
            "buildOptions": ["releaseMode", "optimize", "inline"]
        },
        "release-debug": {
            "buildOptions": ["releaseMode", "optimize", "inline", "debugInfo"]
        },
        "release-nobounds": {
            "buildOptions": ["releaseMode", "optimize", "inline", "noBoundsCheck"]
        }
```

And:

```
It's recommended to avoid this build type and instead change the algorithms that are affected by this the most to do a single bounds check before many array accesses and operate on the ptr field following that. This results in the same performance improvements while not harming safety.
```

Steven Schveighoffer kirjoitti 13.7.2024 klo 4.55:
> The `-release` flag is equivalent to `-O -boundscheck=safeonly -inline`.
> 
> I think we should remove it. If you want no bounds checks, you should have to really want it enough to type that whole monstrosity in. It's trivial to avoid bounds checks by using `.ptr[index]` in `@system` code. In my dub projects, I rewrite the release mode to keep bounds checks for all code, it's that important.
> 
> What do you think? Deprecate for 3 versions, then remove.
> 
> -Steve

Agree. `@safe` ought to mean no undefined behaviour absent compiler bugs or `@trusted` abuse, that should be the default even in release mode.

For the same reason, I also think `-release` shouldn't imply `-check=assert=off`, as long as the spec says that is undefined behaviour (and dmd doesn't explicitly guarantee not optimising based on that).

Maybe I'd go with a longer deprecation period though, like ten releases or so.

Walter Bright kirjoitti 13.7.2024 klo 8.35:
> The -release switch means "make the fastest code". Make it easy for the journalists to do the right thing.
> 
> Nobody new to D will know to use -O -boundscheck-safeonly -inline. They'll just get a "D is slow" result and move on.

Maybe we should have two release switches then. `-release-safe` and `-release-nochecks`, listed side-by-side in the docs. Then a reviewer (or an ordinary user) can hardly notice there is one without noticing the other.

On 7/14/2024 1:44 PM, Steven Schveighoffer wrote:
> The biggest problem I have, I guess, is that it's called "release". It fools people into thinking you should use it for released code.

It's an issue I've run into repeatedly. Reviewers not familiar with a compiler look for a "release" switch for benchmarking.

On 16/07/2024 6:14 AM, Walter Bright wrote:
> On 7/14/2024 1:44 PM, Steven Schveighoffer wrote:
>> The biggest problem I have, I guess, is that it's called "release". It fools people into thinking you should use it for released code.
> 
> It's an issue I've run into repeatedly. Reviewers not familiar with a compiler look for a "release" switch for benchmarking.

Right, but it's dmd we are talking about.

A compiler that no matter what switches are set internally or externally cannot compete with ldc or gdc.

It is better to slap a message both in the version/help message of the compiler and on the site that says "don't use dmd for reviewing of performance of D use ldc/gdc instead".

Given this, it is better to simply remove the switch as it fools people into doing unsafe things that give them a very bad day.

On 7/15/2024 11:20 AM, Richard (Rikki) Andrew Cattermole wrote:
> Right, but it's dmd we are talking about.
> 
> A compiler that no matter what switches are set internally or externally cannot compete with ldc or gdc.

People benchmark it anyway.


> It is better to slap a message both in the version/help message of the compiler and on the site that says "don't use dmd for reviewing of performance of D use ldc/gdc instead".

People doing benchmarks do not read the site. That's the whole problem.


> Given this, it is better to simply remove the switch as it fools people into doing unsafe things that give them a very bad day.

People don't develop code using a -release switch. Those spending time coding in D (rather than spending as little time as possible writing a benchmark) will be likely to spend time reading what a switch does before using it.

I've been in this business a long time. What people should do and what they do do is rarely aligned. People who do comparative benchmarks spend as little time as possible benchmarking a language/compiler they are not familiar with.

Have you ever read the descriptions of all the compiler switches on gcc or VC?

Me neither.

On Wednesday, 17 July 2024 at 15:51:29 UTC, Walter Bright wrote:
> People doing benchmarks do not read the site. That's the whole problem.

then keep -release and if used just output "use ldc2 to build a performant executable" on console instead.