https://herbsutter.com/2018/07/02/trip-report-summer-iso-c-standards-meeting-rapperswil/

This looks to me like a huge step forward for C++....

> * You get to install your own violation handler and ship a release build with the option of turning on enforcement at run time.
> * You get to express audit to distinguish expensive checks to be run only when explicitly requested.
> * You get to express axiom contracts that are intended to never generate run-time code but are available to static analysis tools.
> * Finally, you will likely get better performance, because contracts should enable compilers to perform more optimizations, more easily, than expressing them using assertions.

The last to look very important to me.

I have been looking closely at what the compiler (and splint) does with asserts in our code https://stackoverflow.com/questions/50165291/how-can-one-implement-assert-to-make-use-of-gccs-optimizers-static-dataflo

And found that counter intuitively (in C at least), asserts weakened gcc's static analysis abilities!

> Step 2 is to (gradually) migrate std:: standard library precondition violations in particular from exceptions (or error codes) to contracts. The programming world now broadly recognizes that programming bugs (e.g., out-of-bounds access, null dereference, and in general all pre/post/assert-condition violations) cause a corrupted state that cannot be recovered from programmatically, and so they should never be reported to the calling code as exceptions or error codes that code could somehow handle.

Ah, that's a really nice statement.

Well, D is not exactly known for contract oriented programming or DbC (Design by Contract)
we have to thank Bertrand Meyer and his language Eiffel, for that

On Tuesday, 3 July 2018 at 03:27:06 UTC, Ali wrote:

> we have to thank Bertrand Meyer and his language Eiffel, for that

True.

I was referring to the ideas in Walter's proposal

https://forum.dlang.org/thread/lrbpvj$mih$1@digitalmars.com

On 7/2/2018 7:53 PM, John Carter wrote:
>> Step 2 is to (gradually) migrate std:: standard library precondition violations in particular from exceptions (or error codes) to contracts. The programming world now broadly recognizes that programming bugs (e.g., out-of-bounds access, null dereference, and in general all pre/post/assert-condition violations) cause a corrupted state that cannot be recovered from programmatically, and so they should never be reported to the calling code as exceptions or error codes that code could somehow handle.
> 
> Ah, that's a really nice statement.

So, I have finally convinced the C++ world about that! Now if I can only convince the D world :-)

(I'm referring to the repeated and endless threads here where people argue that yes, they can recover from programming bugs!)

On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
> So, I have finally convinced the C++ world about that! Now if I can only convince the D world :-)
>
> (I'm referring to the repeated and endless threads here where people argue that yes, they can recover from programming bugs!)

It seemed like you were perhaps talking at crossed purposes a little on that. You seemed to advocate blowing up the whole world when anything went wrong while some people were making the point that in some contexts while one bit might explode you could need to keep other things going.

On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
> On 7/2/2018 7:53 PM, John Carter wrote:
>>> In general all pre/post/assert-condition violations) cause a corrupted state that cannot be recovered from programmatically, and so they should never be reported to the calling code as exceptions or error codes that code could somehow handle.
>> 
>> Ah, that's a really nice statement.
>
> So, I have finally convinced the C++ world about that! Now if I can only convince the D world :-)

Oh, I'm convinced.

At work here I have emerged from a long, dark, debate on the subject within the team.

The ultimately solution was to realize there are actually TWO facilities with TWO entirely different purposes that have been overloaded with the same name.

Alas, the word "assert" now is inextricably mired in this confusion.

Half our team used asserts to mean "This mustn't _ever_ happen in unit tests (unless we set up a specific test case for that), and it will never happen if the incoming signal is standards compliant, but it may happen (due to RF noise, and/or competitor violating the standard and/or adding in proprietary stuff into the data and/or we're being attacked) so we _must_ fall through the assert at run time, and handle that case somehow, but preferably make a note that something unexpected happened."

The other half of the team meant, "If the expression is false, it means the code on this line or on the execution path prior to it is definitely defective and must be fixed immediately.

And there is absolutely no hope the code after it will work, and continuing on will make the system flaky and unreliable, and the only path back to reliable function is a reset.

All code after this line may explicitly assume, and depend on, the
expression being true.

Any attempt to handle the possibility of the expression is false is buggy, useless and probably will be removed by the optimizer.

Any urge to handle the possibility of the expression being false after the assert, should be replaced by the inclination to review the code on the execution path prior to the assert, to ensure that the expression will always be true."

Alas, both sides were using the same word "assert" to mean these different things, resulting in conversations that went around and around in meaningless circles.

We have resolved the debate by identifying these two different meanings, and given the facilities implementing them two different names and documenting the difference in meaning and intent.

On Thu, Jul 05, 2018 at 10:05:44PM +0000, John Carter via Digitalmars-d wrote: [...]
> At work here I have emerged from a long, dark, debate on the subject within the team.
> 
> The ultimately solution was to realize there are actually TWO facilities with TWO entirely different purposes that have been overloaded with the same name.
> 
> Alas, the word "assert" now is inextricably mired in this confusion.
> 
> Half our team used asserts to mean "This mustn't _ever_ happen in unit tests (unless we set up a specific test case for that), and it will never happen if the incoming signal is standards compliant, but it may happen (due to RF noise, and/or competitor violating the standard and/or adding in proprietary stuff into the data and/or we're being attacked) so we _must_ fall through the assert at run time, and handle that case somehow, but preferably make a note that something unexpected happened."
> 
> The other half of the team meant, "If the expression is false, it means the code on this line or on the execution path prior to it is definitely defective and must be fixed immediately.
[...]

In D, I believe the first meaning is assigned to "enforce" (i.e.,
std.exception.enforce), and the second meaning is assigned to "assert"
(the built-in assert).

Unfortunately, the word "assert" has been used outside the context of D to mean either thing, so people keep tripping over the terminology and using assert for the wrong thing.  And it doesn't help that "enforce" is a library function rather than a built-in construct, which some people wrongly interpret as "secondary, therefore somehow inferior, and probably not what I intend".


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr

On 7/5/2018 3:26 PM, H. S. Teoh wrote:
> people keep tripping over the terminology

Some people do. However, the long threads of debate on this topic was with people who were clear on what the terminology meant.

On 7/6/18 4:21 AM, Walter Bright wrote:
> On 7/5/2018 3:26 PM, H. S. Teoh wrote:
>> people keep tripping over the terminology
> 
> Some people do. However, the long threads of debate on this topic was with people who were clear on what the terminology meant.

My question has never been the difference between programming and input errors. My question always has been how the compiler ascribes programming errors to things that could easily also be checkable and recoverable, depending on context. For instance, array bounds checks. D makes this choice for you, and it's unfortunate to have to check things twice, or not rely on the compiler to insert those checks.

But luckily D is powerful enough to add types that do the right thing :)

-Steve

On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
> On 7/2/2018 7:53 PM, John Carter wrote:
>>> Step 2 is to (gradually) migrate std:: standard library precondition violations in particular from exceptions (or error codes) to contracts. The programming world now broadly recognizes that programming bugs (e.g., out-of-bounds access, null dereference, and in general all pre/post/assert-condition violations) cause a corrupted state that cannot be recovered from programmatically, and so they should never be reported to the calling code as exceptions or error codes that code could somehow handle.
>
> So, I have finally convinced the C++ world about that! Now if I can only convince the D world :-)


But that's not how D works. It throws an Error which can be caught.

If people are allowed to do something they assume it's legitimate.

It should be a compile time error to catch an Error, but it doesn't even emit a warning and it seems to work well which is probably proof enough for people to assume it's good.

In my opinion it shouldn't throw an error but abort at once after printing the stack trace. Which would have the nice side effect of stopping almost exactly on the line in a debugger.

An out of bounds range error for instance prints the assertion message and then gracefully exits (exit code is 1, which indicates a code that can be handled by the calling process, rather than a return code of -6 for abnormal termination).

Also there is, or at least was a few months ago, that gotcha in concurrency that when a thread throws an Error it goes silent, the thread simple gone.
The only way I could finally get to the root of the cause was to catch everything in that thread.
Aborting would be preferable so the debugger can catch such things. Makes it a matter of rerunning the program instead of hours of bug hunting and guess work.
Also in spite of the above, a bug in a thread should probably bring down the whole program since if a thread is in unrecoverable, corrupt state, it follows that the entire program is in corrupt state.