On Friday, 23 June 2017 at 21:14:47 UTC, MysticZach wrote:
On Friday, 23 June 2017 at 20:49:35 UTC, Moritz Maxeiner wrote:
Normal usage of the new syntax? If asserts later on get a
(possibly breaking) syntax overhaul that will affect (and
forward breakage to) the contract syntax, as well, if it uses
the same compiler infrastructure.
My naive assumption is that any improvement in the in/out
grammar would also apply to asserts, and vice versa.
Why should it? Contracts are not asserts or vice versa.
I 95% disagree. As far as I can tell, they are _very_ similar.
The only difference I can see is that when you violate an `in`
contract, the exit message should point to the caller instead
of the callee as the source of the problem. Beyond that, they
seem like little more than glorified `assert`s.
This is (unfortunately) not a matter of opinion (within the
context of DbC), see Meyer's original publication [1], who
effectively birthed and established the DbC paradim.
Contracts within the DbC paradigm *are* abstractions that do not
necessitate any particular implementation. Most native languages
simply (sensibly) choose to use asserts for that.
I'm not sure what you're getting at here. With the proposal
Timon implemented we have the following:
- the newer, decoupled contract syntax that separates contract
specification and implementation from each other; Timon's
implementation uses asserts as the internal contract
implementation AFAIK
Not exactly. It actually _couples_ `in` expressions with assert
expressions. In essence it just lowers
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).
Otherwise, it couples contracts with the request of "you take
care of the implementation for me", which Timon's dmd
implementation just happens to be use asserts for as the default
(which is fine).
[1] Meyer, Bertrand: Design by Contract, Technical Report
TR-EI-12/CO, Interactive Software Engineering Inc., 1986
