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

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 16:52:24 UTC, MysticZach wrote:
>
> Well I'd be just as happy expanding the design limits of the 
> language, i.e. `assert`, if that were a better option. The 
> issue you raise is just how different are `in` and `out` 
> contracts from regular `assert` contracts.

Well, a contract is an abstraction, asserts are just one possible 
implementation; so yeah, they are different things.
Technically in the current (verbose) syntax, the `assert` just 
happen to be part of the contract's implementation; it could 
really be just anything, including `in { if (!cond) throw 
Exception }`.

> They _are_ all listed in the same section of the documentation 
> [1], for whatever that's worth.

Well, yeah, because assert's are the most common contract 
implementation in D.

>
> The practical question is whether one can assume that the same 
> semantics used for `assert`, whatever they may be, will in all 
> cases be desirable for `in` and `out` too. The flexibility of 
> decoupling them is one solution, if they are clearly 
> sufficiently different.

They are (see abstraction vs implementation argument above). We 
can just as well use another implementation in the new syntax and 
then we don't have to worry about asserts semantics possibly 
changing in the future anymore. Also, people arguing for changes 
in assert semantics don't have to care about contracts if they 
don't also do DbC. I think decoupling is the way to go here.

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

> I don't know what to suggest, because I don't if `assert` can 
> be made good enough to warrant direct inclusion into the 
> grammar. If it could, then all contracts, including plain 
> `assert` statements, would benefit from them.

Well, for me it would be this:
- The compact syntax with `in (cond)` and `out (ident)(cond)`
- Don't lower those contracts directly to any fixed 
implementation; lower them to a template (similar to what I 
posted) that you stick in druntime instead
- Allow configuring the template's checking semantics via D 
versions (you can still then have one implementation choice in 
the template be asserts, if you want, though I would go with a 
more riguruous kill switch such as the one I posted)

I would definitely be interested in helping out with the template 
implementation for druntime, btw.