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

[MysticZach via Digitalmars-d]

On Friday, 23 June 2017 at 21:36:07 UTC, Moritz Maxeiner wrote:
> Contracts within the DbC paradigm *are* abstractions that do 
> not necessitate any particular implementation.

In practice, though, what must any such implementation actually 
achieve?

1. allow the source code to express its intent to the reader
2. prevent programs in invalid states from continuing
3. provide information about those invalid states after the fact

Goal 1 lies in the domain of the language grammar.
Goals 2 and 3 reflect the behind-the-scenes implementation of 
that grammar.

> Most native languages simply (sensibly) choose to use asserts 
> for that.

Which could mean that they use the grammar of asserts, e.g. 
`assert(a, "message");`, or that they use a specific 
behind-the-scenes implementation of that grammar, i.e. the code 
that such a grammar compiles to.

> It would only couple the contracts with asserts if the DIP also 
> specifies that asserts *must* be used for the lowering (which I 
> would be against btw).

I think this reveals the sticking point. I think that the way D 
compiles assert expressions can and should be improved by making 
it more flexible behind the scenes. But that doesn't necessarily 
mean that the grammar needs to change. The problem is that we 
need to put *some* grammar into the new `in` expression design. 
If we allow, for example, a random sequence of function 
arguments, e.g.`in(a, b < 0, "yay!", myDvar)` there is no go-to 
way to implement it. The surface code would then require a 
particular backend implementation that could handle the grammar, 
and would furthermore now be coupled with that implementation. 
I'd rather not deal with that problem. It's vastly easier to just 
put my faith into the `assert` grammar, and hope that any 
improvements that it needs and receives will apply equally to 
`assert`s as well.