assert semantic change proposal

[H. S. Teoh via Digitalmars-d]

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