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

[Moritz Maxeiner via Digitalmars-d]

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

I would put the selection mechanics and prefinded semantics into 
druntime, e.g. under core.contracts.
In particular I'm thinking about Insister [1] and if it makes 
sense to put something like that in core.contracts, expose a 
`IInsister theContractChecker` that can be overwritten at runtime 
and have the compiler lower contract checks to 
`theContractChecker.insist` calls.
I'm not sure if that is the best way to go forward, but it would 
be nice for the configurability to be remain in language 
constructs without requiring addition of compiler options, I 
think.

>
>> DIP1003 did not introduce an entirely new system, it merely 
>> slightly changed an existing sytem.
>> DIP1009 *does* introduce several new syntax forms, i.e. adding 
>> a whole new system, which means it *also* introduces the 
>> responsibility of maintaining backwards compatibility when 
>> someone tries to improve contracts again (and then we would 
>> have three systems to specify contracts).
>
> Okay, I'm a convert. Although still one big downside is that 
> DbC in D is somewhat impaired, as H.S. Teoh pointed out [1].

Yay!
Regarding the location of contract checking: Yes, though I agree 
with him that a fix for that need not be part of this DIP. If 
this DIP cleanly separates contract specification from contract 
implementation, we can address it separately. In particular, if 
something like Insister gets chosen as the framework, then the 
issue of contract checking not occuring on the caller site should 
be fixable simply by changing where the compiler injects the 
lowered `theContractChecker.insist` into.

[1] 
http://forum.dlang.org/post/pdqdaktjifgajiwnpxaz@forum.dlang.org