assert semantic change proposal

[Sean Kelly via Digitalmars-d]

On Wednesday, 6 August 2014 at 21:16:42 UTC, David Bregman wrote:
> On Wednesday, 6 August 2014 at 20:27:45 UTC, Sean Kelly wrote:
>> Well, it seems like the underlying idea is to treat assertion 
>> failures more strongly than we do now.  So changes in how 
>> these are handled by the runtime might be a side effect of 
>> this proposal.
>
> Again, since Walter's proposal only affects release mode, I 
> don't see how exceptions or the runtime are related. What am I 
> missing? You agree assertion failures (AssertError) are only 
> thrown in debug mode, right?

In non-release mode, but yes.  However:

4. An assert failure is a non-recoverable error. The compiler may 
assume that
execution does not proceed after one is tripped. The language 
does allow
attempts to shut a program down gracefully after one is tripped, 
but that must
not be misconstrued as assuming that the program is in a valid 
state at that point.

5. assert(0); is equivalent to a halt, and the compiler won't 
remove it.


Clearly, the intention is for assertion failures to terminate the 
program, but that isn't done now.  Or at least this isn't done in 
the multithreaded case.  So I was asking for clarification on 
what should be done on that end, and whether that behavior should 
inform how assert is treated from a language perspective.