On 09/01/2018 04:15 PM, Walter Bright wrote:
> https://blog.regehr.org/archives/1091
> 

This does make me think of one thing: Shouldn't assert expressions be required to be pure? (even if only weakly pure)

Not sure how much practical problems that would create, but at least in theory it certainly sounds like the right thing.

On Sunday, September 2, 2018 1:52:34 PM MDT John Colvin via Digitalmars-d wrote:
> > If the compiler can add @safe optimizations based on assertions, then that's fine with me (though I know that some others don't agree), but they have to be @safe even when the assertion would have failed if it were compiled in. If they're ever @system, then @safe isn't actually @safe.
>
> I believe asserts are the general case of which bounds checking is a specific instance. @safe code is only @safe if bounds-checking is enabled for @safe.
>
> void foo(int[] a) @safe
> {
>      a[0] = 1;
> }
>
> is only really guaranteed safe if a bounds check is done, because [] is a valid array for a caller to pass.

Well, if that were the intention, then -release could not remove assertions from @safe code. -release does not remove bounds checking from @safe code. You have to use -boundscheck=off to disable assertions in @safe code (which is of course discouraged, since it makes the code not @safe). So, if we were to decide that assertions had to be left in for code to stay @safe, then we would have to start leaving them in in @safe code when -release is used and only compile them out with a new flag specifically for compiling out assertions in @safe code. And that would have pretty far-reaching effects given that it's very much understood right now that -release removes assertions. And personally, I'd probably use assertions a lot less if they were going to be left in with -release. So, while I think that that's a better approach that allowing @system optimizations in @safe code when assertions are removed, I can't say that I think that it's a great idea - though the folks who pretty much always want assertions enabled would probably like it (though they can already just skip -release).

- Jonathan M Davis

On Monday, 3 September 2018 at 06:26:59 UTC, Jonathan M Davis wrote:
> Well, if that were the intention, then -release could not remove assertions from @safe code. -release does not remove bounds checking from @safe code. You have to use -boundscheck=off to disable assertions in @safe code (which is of course discouraged, since it makes the code not @safe). So, if we were to decide that assertions had to be left in for code to stay @safe, then we would have to start leaving them in in @safe code when -release is used and only compile them out with a new flag specifically for compiling out assertions in @safe code. And that would have pretty far-reaching effects given that it's very much understood right now that -release removes assertions. And personally, I'd probably use assertions a lot less if they were going to be left in with -release. So, while I think that that's a better approach that allowing @system optimizations in @safe code when assertions are removed, I can't say that I think that it's a great idea - though the folks who pretty much always want assertions enabled would probably like it (though they can already just skip -release).
>
> - Jonathan M Davis

Yes, the command line interface needs to make it easy and obvious to do the right thing.

On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote:
> https://blog.regehr.org/archives/1091
>
> As usual, John nails it in a particularly well-written essay.
>
> "ASSERT(expr)
> Asserts that an expression is true. The expression may or may not be evaluated.
> If the expression is true, execution continues normally.
> If the expression is false, what happens is undefined."
>
> Note the "may or may not be evaluated." We've debated this here before. I'm rather pleased that John agrees with me on this. I.e. the optimizer can assume the expression is true and use that information to generate better code, even if the assert code generation is turned off.

I used to completely agree with your position about asserts being used for optimization purposes, until I realized that part of your position was for asserts to be used as optimization hints *even if they aren't checked*.

This battle has been fought over and over, with no movement on either side, so I'll just comment that nobody what John Nails or anyone else says, my personal opinion is that you're 100% wrong on that point :-)

On Sunday, 2 September 2018 at 21:12:39 UTC, Nick Sabalausky (Abscissa) wrote:
> This does make me think of one thing: Shouldn't assert expressions be required to be pure? (even if only weakly pure)
>
> Not sure how much practical problems that would create, but at least in theory it certainly sounds like the right thing.

Exactly. You may still catch assert(!fclose(f)) but not other non-obvious functions.
Nice trick to find them in C:
https://stackoverflow.com/questions/10593492/catching-assert-with-side-effects/35294344#35294344

On 9/2/2018 2:12 PM, Nick Sabalausky (Abscissa) wrote:
> On 09/01/2018 04:15 PM, Walter Bright wrote:
>> https://blog.regehr.org/archives/1091
>>
> 
> This does make me think of one thing: Shouldn't assert expressions be required to be pure? (even if only weakly pure)
> 
> Not sure how much practical problems that would create, but at least in theory it certainly sounds like the right thing.

It's come up before. The trouble comes when the code doing the evaluation has side effects which are benign to the function being compiled, and these can be useful. For example, it could read a mutable global variable.

On Monday, 3 September 2018 at 16:53:35 UTC, Meta wrote:
> This battle has been fought over and over, with no movement on either side, so I'll just comment that nobody what John Nails or anyone else says, my personal opinion is that you're 100% wrong on that point :-)

Well, John Regehr seems to argue that you shouldn't use asserts for optimization even if they are turned on as the runtime might override a failed assert.

«As developers, we might want to count on a certain kind of behavior when an assertion fails. For example, Linux’s BUG_ON() is defined to trigger a kernel panic. If we weaken Linux’s behavior, for example by logging an error message and continuing to execute, we could easily end up adding exploitable vulnerabilities.»

So…

On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote:
>
> Note the "may or may not be evaluated." We've debated this here before. I'm rather pleased that John agrees with me on this. I.e. the optimizer can assume the expression is true and use that information to generate better code, even if the assert code generation is turned off.

Is the part about the optimizer true in D's case? Or is this just a theoretical advantage to using asserts that are not evaluated in production code but left in?

On Wed, Sep 05, 2018 at 03:59:06PM +0000, Michael via Digitalmars-d wrote:
> On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote:
> > 
> > Note the "may or may not be evaluated." We've debated this here before.  I'm rather pleased that John agrees with me on this. I.e. the optimizer can assume the expression is true and use that information to generate better code, even if the assert code generation is turned off.
> 
> Is the part about the optimizer true in D's case? Or is this just a theoretical advantage to using asserts that are not evaluated in production code but left in?

AFAIK, no optimizer currently actually takes advantage of asserts in this way.  But Walter has stated that this was his intention all along when he made asserts a part of the language (as opposed to, e.g., a macro / standard library call in C).

However, whenever he talks about this, there's always a big controversy about potential pitfalls, and opinions are divided on this issue.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."

On Wednesday, 5 September 2018 at 10:30:46 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 3 September 2018 at 16:53:35 UTC, Meta wrote:
>> This battle has been fought over and over, with no movement on either side, so I'll just comment that nobody what John Nails or anyone else says, my personal opinion is that you're 100% wrong on that point :-)
>
> Well, John Regehr seems to argue that you shouldn't use asserts for optimization even if they are turned on as the runtime might override a failed assert.
>
> «As developers, we might want to count on a certain kind of behavior when an assertion fails. For example, Linux’s BUG_ON() is defined to trigger a kernel panic. If we weaken Linux’s behavior, for example by logging an error message and continuing to execute, we could easily end up adding exploitable vulnerabilities.»
>
> So…

I don't disagree. I think the only sane way to use asserts as an optimization guide is when the program will abort if the condition does not hold. That, to me, makes perfect sense, since you're basically telling the compiler "This condition must be true past this assertion point, because otherwise program execution will not continue past this point". You're ensuring that the condition specified in the assert is true by definition. Not having that hard guarantee but still using asserts as an optimization guide is absolutely insane, IMO.