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

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 22 June 2017 at 13:11:12 UTC, MysticZach wrote:
> On Thursday, 22 June 2017 at 12:54:00 UTC, MysticZach wrote:
>> On Thursday, 22 June 2017 at 10:59:18 UTC, Moritz Maxeiner 
>> wrote:
>>> Again, that's not what H.S. Teoh's proposal would do. All it 
>>> does is install an *implementation agnostic*, *abtract* way 
>>> to specify contracts into the grammar. Whether that is 
>>> lowered to assert, or anything else is an implementation 
>>> detail and it certainly isn't fixed to asserts.
>>
>> Okay. Then the proposal needs to be accompanied by an explicit 
>> description of how to hook into the new semantics. Which is 
>> what you provided, but I suppose it would need to be exactly 
>> specified. In particular, where exactly is the code for the 
>> (optional) user-defined hook to be found? In a separate file, 
>> maybe as indicated with a command line option, e.g. 
>> `-contractsConfig=myContracts.d`?
>
> As long as one is doing this, maybe a proposal for user-defined 
> `assert` should be provided too? It'd be interesting to have a 
> dedicated file for user-defined assert and contract 
> configuration. The core idea is to allow *everyone*, from large 
> companies to individual hobbyists, to use `assert`, `in`, and 
> `out`, and have it work the way they want. I would definitely 
> need help writing that DIP.

Upon reflection, that is exactly what my Insister proposal is :p
The reason it's not called Asserter, btw, is that assert is a
a) a keyword, and
b) is already deeply entrenched with the concept of Errors 
(bugs), in D
and that `enforce`, is also de facto established for Exceptions 
(user input error),
so `insist` would then be a configurable chooser between the two.