Maybe D was wrong on contracts

[H. S. Teoh]

On Tue, Sep 08, 2026 at 10:23:37PM +0000, Quirin Schroll via Digitalmars-d wrote:
[...]
> There might be a case for deprecating contract blocks entirely in
> favor of contract statements, i.e. no more `in { doWhatEverIWant();
> }`, only `in(Expression)` because the `Expression` must return a
> `bool` (or be convertible to one). Then, `Expression == false` is a
> contract violation, `Expression == true` is success. A thrown
> `Exception` should be “promoted” to an `AssertError`, and a thrown
> `Error` shouldn’t be touched. If a contract is more complex than a
> series of `in`/`out`/`invariant` expressions, a private function that
> returns a `bool` is probably more readable anyway; an immediately
> invoked lambda is also possible.
[...]

That, or deprecate contracts that assert, and have them return a bool
instead.

Having contracts return bool instead of asserting gives the compiler a
way to emit logic to handle things like covariant / contravariant
handling in class hierarchies that doesn't involve evil hacks around the
semantics of `assert` and catching AssertError's (and dabbling with
what's technically UB per language spec).


T

-- 
This is a tpyo.