On 10/11/2017 02:27 AM, John Burton wrote:
> The spec says this :-
>
> "As a contract, an assert represents a guarantee that the code must
> uphold. Any failure of this expression represents a logic error in the
> code that must be fixed in the source code. A program for which the
> assert contract is false is, by definition, invalid, and therefore has
> undefined behaviour."
The important part is that the "program" has undefined behavior
according to *your* definition because you're the one who asserted that
something should never have happened:
struct Square {
int side;
int area;
invariant() {
assert(area == side * side); // Could be inside foo()
}
void foo() {
}
}
void main() {
auto s = Square(1, 10);
s.foo();
}
So, you think you wrote your program to never break that assertion. So,
regardless of the reason for the failure (design error, memory
corruption, hardware error, etc.), the program is outside of its
well-defined state (by you).
> I know this might seem like a small or pedantic point
Not only this specific point, but almost everything about assertion
failures are very important and very interesting. For example, according
to the text you quoted; the code injected by the compiler, the one that
dumps a backtrace for an Error, should not be executed either. You have
no guarantee that that code will really dump a backtrace, whether the
output will be correct, etc. :/ (There has been many many long
discussions about these topics on the D newsgroups.)
What gives me comfort is the fact that life is not perfect anyway.[1]
Things somehow seem to work fine. :)
Ali
[1] Another example is mouse clicks (and screen taps). We have no
guarantee that we are clicking what we wanted to. Sometimes a new window
pops up and you click some random button but it works in general.
