DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

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`.