Automatic invariant generation

[Jonathan M Davis via Digitalmars-d]

On Monday, July 10, 2017 11:26:43 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote:
> > For some assertions, having more than a file and line number is nice
> > (e.g. if you have messages for your pre-condition assertions, then you
> > can make it so that when it fails, the programmer doesn't even need to
> > look at the source code),
>
> He always needs to look at the source code. Asserts are for BUGS, and to
> fix bugs, you gotta look at the code. If asserts are being used as a
> substitute for input/environment errors, they're misused.
>
> In 40 years of asserts, I can't think of ever not visiting the file/line
> where it failed as the first thing I did to debug it.

Yes, assertions are used for catching bugs, but when they're used for DbC,
the bug is in the caller, and if it's clear from the message that the caller
violated a pre-condition as well as what that pre-condition was, then there
really is no need for the programmer to look at the source code of the
function being called. They just need to look at their code that's calling
it and figure out how they screwed up and passed a bad value. Essentially,
with pre-conditions, it's really the caller's code that's being tested, not
the code where the assertion itself is.

Assertions which test the code that they're actually in, on the other hand,
pretty much always require that you look at that code to figure out what's
going on.

- Jonathan M Davis