assert semantic change proposal

[Walter Bright via Digitalmars-d]

On 8/6/2014 5:22 PM, Sean Kelly wrote:
> On Wednesday, 6 August 2014 at 22:01:47 UTC, Walter Bright wrote:
>> On 8/6/2014 12:34 PM, Sean Kelly wrote:
>>> There is no facility for forcing a clean termination of another
>>> thread.
>>
>> Understood - so the only option is to force an unclean termination.
>
> So in all cases, it seems like what we should be doing is call exit(1) or the
> equivalent and forego any attempt at cleanup. Otherwise an assertion failure in
> a spawned thread would be handled even more strongly than in the main thread.
>
> Alternately, if we build on std.concurrency we could have the next call to
> receive throw a FatalError or something to force it to terminate.  But there's
> no telling how long this would be.  I assume you prefer the forceful route.

Yes, I prefer that.


>> Let me emphasize that when an assert trips, the program has failed. It is in
>> an invalid, unknown, indeterminate state from that moment forward.
>
> I think in many cases the scope of possible invalid states can actually be
> determined given a reasonable understanding of the program.  For example, if a
> thread within a @safe app encounters an error, it might be possible to assert
> that the damage does not extend beyond the limits of data referenced by the
> thread.

I can't agree with that, especially not for the standard library.


>> Use enforce() for errors that are anticipated and cleanly recoverable, not
>> assert().
>
> Given what I said above, I'm inclined to say that enforce() should be used by in
> contracts and the like rather than assert(), and to save assert() for the
> situations where I'm certain there's absolutely nothing to be done.  However, I
> think of enforce() to be more for run-time problems that might be corrected by
> trying again later with the same input.  I'll have to give this some thought.