On 07/31/14 02:31, Walter Bright via Digitalmars-d wrote: > On 7/30/2014 3:53 PM, Artur Skawina via Digitalmars-d wrote: >> No, with the assert definition you're proposing, it won't. It would >> be allowed to optimize away the bounds check. And this is just one of >> many problems with the assert==assume approach. > > Please explain how assume would behave any differently.
I'm not arguing for assume [1], just against allowing information derived from assert expressions being able leak and affect other parts of the program. That just can not work (sanely); it would cause more problems than C's undefined behavior abuse. Because the UB triggers are well defined - by the language - and relatively well known. Asserts are /user-defined/. One wouldn't be able to reason about code without considering every single assert expression that was evaluated before reaching the current expression/function. An incorrect or inexact assert() hidden away somewhere could silently affect unrelated code, disable important safety checks etc. artur [1] I don't think that introducing `assume` would make a significant difference at this point - there are many more important D issues needing attention... But it could be done, would need to be @system, and probably wouldn't require much work. In fact, it already exists in gdc-ese, kind of: static import gcc.attribute; enum inline = gcc.attribute.attribute("forceinline"); @inline void assume()(bool c) { import gcc.builtins; if (!c) __builtin_unreachable(); } bool plain_assert(int i) { assert(i<6); return i==9; } // => "cmpl $9, %edi; sete %al; ret" bool assume_instead_of_assert(int i) { assume(i<6); return i==9; } // => "xorl %eax, %eax; ret" `assume`, unlike `assert`, may affect codegen.