assert semantic change proposal
H. S. Teoh via Digitalmars-d
digitalmars-d at puremagic.com
Thu Aug 7 10:54:53 PDT 2014
On Fri, Aug 08, 2014 at 03:44:06AM +1000, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d" wrote in message
> news:mailman.674.1407424873.16021.digitalmars-d at puremagic.com...
>
> >> And we've also got asserts in pre-conditions, which are recoverable
> >> by definition.
> >
> >Huh, what? I thought asserts in pre-conditions are non-recoverable,
> >because they imply that user code has broken the contract governing
> >the use of that function.
>
> I meant asserts in pre-conditions when used with inheritance. It's a
> pass if any of the preconditions pass, so the compiler runs them in
> turn and catches all but the last.
Oh, I see it now.
Hmph. Now it's making me wonder if preconditions should be treated as a
*single* assert outside the body of 'in{}', rather than allowing
individual asserts inside. Perhaps the body of 'in{}' should return a
boolean where false indicates a failed precondition, so that instead of
writing:
auto func(...)
in {
assert(cond1);
assert(cond2);
assert(cond3);
}
body { ... }
you'd write instead:
auto func(...)
in { cond1 && cond2 && cond3 }
body { ... }
and the compiler translates this to:
bool __func__in(...) { return cond1 && cond2 && cond3; }
auto func(...) {
assert(__func_in(...));
// body goes here
}
Well, technically it should be the caller that invokes __func_in(), but
that's a different issue.
T
--
We are in class, we are supposed to be learning, we have a teacher...
Is it too much that I expect him to teach me??? -- RL
More information about the Digitalmars-d
mailing list