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

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 22, 2017 at 05:46:06AM +0000, MysticZach via Digitalmars-d wrote:
[...]
> As far as syntax subtrees not belonging to their parent, I can see
> where the cognitive dissonance comes from. But it just doesn't seem
> that bad to me, since contracts are always executed as if they are
> sequential statements anyway.
[...]

Then possibly you're missing the point behind DbC.  The idea of
"executing" a contract seems to indicate that you're taking the current
D implementation of it as normative. However, that is not the case.  The
concept behind DbC is that the function specifies a set of conditions
the caller must satisfy before calling it (the in-contract), and in
return it promises to satisfy another set of conditions (the
out-contract).  Conceptually speaking, the contracts are not "executed"
as if they were part of the code in the function's body; rather, they
are checks that are made by the runtime (as a conceptual entity -- one
might think of it as a circuit breaker or some such safeguarding device)
such that if they are violated, the program is aborted because it has
entered an invalid state from which further execution would lead to UB.

Of course, how you implement the DbC concept is a different (albeit
related) issue. In languages targeted for a VM like Java, one could
conceivably implement contract verification as part of the VM itself, so
that it is done "transparently" to user code.  In languages like D,
however, because we're targeting the machine directly, no such
intermediate layer exists, and hence the natural choice of implementing
contracts as part of the code. (Though, as I've said in another post,
D's implementation leaves some things to be desired, such as
in-contracts being part of the callee rather than the caller, which IMO
would have been a better choice.)

But in any case, the so-called "cognitive dissonance" comes from
conflating contracts, which conceptually is part of the function's
user-facing API, as opposed to the implementation details in the
function body.  It's like saying that the locking mechanism of the
safety cap of a medicine bottle is part of the medicine's chemistry. The
locking mechanism is intended to protect the medicine, e.g., from
children who would suffer unintended consequences of the medicine's
chemistry by their incorrect usage of it. But that hardly makes the
safety mechanism the same thing as the medicine itself.  Similarly, the
in-contract of a function is intended to protect it from incorrect usage
by buggy callers, but that hardly makes it a part of the function's
body.


T

-- 
Береги платье снову, а здоровье смолоду.