checkedint call removal

[Artur Skawina via Digitalmars-d]

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.