https://issues.dlang.org/show_bug.cgi?id=23996

--- Comment #6 from elpenguin...@gmail.com ---
(In reply to Bolpat from comment #5)
> (In reply to elpenguino+D from comment #1)
> > I think assert(expr) could provide this functionality. Maybe with a
> > -checkaction=assume switch? It would also work for contracts, invariants,
> > etc then, while also making it trivial to test the assumptions.
> 
> I’d say this is really bad design. An assertion and an assumption mean
> totally different things. With a compiler flag, you control all of them at
> once.
> 
> Just for an example, an assumption can be used to inform the compiler about
> a truth that its optimization routines can make use of and that its
> optimization routines could not figure out themselves.
> An assert might be used to validate function input, e.g. `isPrime(int x)`
> might `assert(x > 0)`.

An assertion is just an enforced assumption. They both mean the same thing.

assert():
- code following is optimized with the assumption that the condition is true
- undefined behaviour if condition is false

pragma(assume):
- code following is optimized with the assumption that the condition is true
- undefined behaviour if condition is false

It is legal for assert() to influence the optimizer without actively checking
the condition, and this proposal would also allow a compiler to actively check
and enforce the condition in pragma(assume) - it is undefined behaviour, and it
might be useful to prove your assumptions while debugging.

Enabling assertions to be treated as unchecked assumptions additionally allows
for invariants and contracts to influence optimizations, though current
compilers don't appear to be capable of optimizing invariants...

--

Reply via email to