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.
