On Wednesday, 21 June 2017 at 17:38:02 UTC, Moritz Maxeiner wrote:
But another option is simply to upgrade `assert` to make sure
it offers what everyone wants.
That would be really cool, but I doubt it will be feasible
here. I think that in this case it will more likely end up with
everyone hating that universal solution equally.
Well the universal solution could be, for example, the
suggestions from my post in the other thread:
3. Allow an additional compiler flag for more informative, but
heavier asserts, e.g. `-release=informativeAsserts`.
4. Allow a pragma in the code, e.g. `pragma(asserts,
none/regular/informative)` for what kinds of asserts are to be
used at a given moment.
This would be added flexibility, rather than a one-size-fits-all
solution. So the word "universal" is a little deceptive. The
options could also include a user-defined hook for assert.
Question: If `assert` itself allowed a user-defined hook, what
would the remaining justification be for decoupling `in` and
`out` contracts from the `assert` logic?
That's what I mean by thinking the problem might be fixable by
upgrading `assert`.
