assert semantic change proposal

[David Bregman via Digitalmars-d]

On Wednesday, 6 August 2014 at 21:35:26 UTC, Sean Kelly wrote:
> 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.

Ah, ok. So it's an issue with the existing implementation not 
matching some other expectations, not related to the main topic 
of this thread. Sorry for the confusion.

Anyway, Walter just replied to your first post, I'll defer to him 
on this.