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 -- Береги платье снову, а здоровье смолоду.