assert semantic change proposal

[John Carter via Digitalmars-d]

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.