On Thursday, 5 February 2015 at 00:43:04 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function
signature. Contracts should be encouraged and increased, not
discouraged.
I agree. Moreover, if the assert fails in the contract, in
theory, we
can point the error at the user's code. An assert inside the
function is
the function's responsibility. An assert in an in contract is
the
caller's responsibility. They're semantically different (even
if dmd
treats them the same way)
Yah I concede this is a good point. Yet we're looking at an
actual liability and are supposed to look at some vague
possible future benefit. -- Andrei
I have an idea. Treat all assert statements which come before the
first non-assert statement as part of the 'in' contract. I'm not
saying the compiler has to generate a whole 'in' function, but
these asserts can be internally tagged to behave *as if* in an
'in' contract. That solves the tooling problem and the
too-much-code problem, no?
