On Sun, Sep 09, 2018 at 12:27:52AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
> IIRC, Weka has different types of assertions to differentiate between these two approaches - one for the cases which absolutely must not happen in production, and one that's purely for catching problems during developement.  And really, I think that that's probably the right approach.
[...]

On Sun, Sep 09, 2018 at 09:20:11PM +0000, John Carter via Digitalmars-d wrote: [...]
> > > Let's face it, the term "assert" has been poisoned by decades of ambiguity.
[...]
> I beg humanity to give up on that word "assert" and come up with others words and define explicit the intent and meaning and implications.
> 
> So much pain will be avoided.

Indeed.  D already distinguishes between assert (for catching programming errors) and enforce (for catching runtime conditions like bad user input).  It's high time we distinguished between the various flavors of assert, preferably with new words to avoid the baggage that has accumulated around 'assert'.

I propose:

- 'assume': aborts on false condition in debug builds, not checked in
  release builds, used as optimizer hint;

- 'insist': aborts on false condition in debug builds, aborts on false
  condition in release builds, used as optimizer hint;

- 'uphold': aborts on false condition in debug builds, aborts on false
  condition in release builds, NOT used as optimizer hint;

- 'allege': logs error and aborts on false condition in debug builds,
  logs error and continues on false condition in release builds, NOT
  used as optimizer hint;


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel