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

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 17:55:05 UTC, MysticZach wrote:
>
> 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?

Because then you won't have normal asserts and contracts be 
subject to different semantics?
If I use a library, I may very well want to disable the library's 
internal assert checks (because I have enough experience that 
it's working properly), but keep it's contracts alive, because my 
code is still shiny new and riddled with bugs.