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.digitalmar...@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