On Sunday, 3 August 2014 at 22:19:16 UTC, Ola Fosheim Grøstad
wrote:
But go ahead. This will lead to a fork.
What should fork is the two opposing intentions for assert.
They should have two different names and different consequences.
On Sunday, 3 August 2014 at 22:18:29 UTC, John Carter wrote:
It comes down to two opposing view of what we use asserts for.
To give a more concrete example of this... in the team I work
with we have the following issue.
When the DbC type programmers turn "asserts are fatal" on, we get
asserts firing all over the place in non-DbC programmers code.
On closer inspection these come down to things like "stupid
factory didn't connect cable A to device B, the installation
instructions are clear, the cable always should be attached in
the production model".
And the solution is one of...
* Find a Device B and plug cable A into it.
* There is a bug somewhere in the firmware.
* There is a bug in the firmware of device B
* You have a debugger in the entrails of device B, so the
heartbeat stopped.
* Something somewhere increased the latency so the timeout
fired, maybe increase timeout..
Whereas for DbC programmers a pre-condition assert firing meant
_very_ directly that the function that _directly_ invoked me is
clearly defective in this manner. The bug is undoubtably there,
there may be a bug elsewhere as well, but it is undoubtably a bug
in my calling routine if it let defective values propagate as far
as me.
Or if a postcondition assert fired, it means, _this_ function is
defective in this manner.
The simple harsh fact is DbC type programmers mean completely
different things to non DbC type programmers by "assert", yet
unfortunately it is mapped on to the same thing with the same
name.
The obvious simple correct resolution is to give them two
different names.
