checkedint call removal

[Chris Cain via Digitalmars-d]

On Saturday, 2 August 2014 at 06:08:43 UTC, Tofu Ninja wrote:
> On Saturday, 2 August 2014 at 05:07:58 UTC, Chris Cain wrote:
>
>> Actually, I'm going to clarify this: Your assertion is *not* 
>> the promise. Your assertion is simply a statement of fact 
>> (note, that does not mean it's a fact, as that appears to be a 
>> point of confusion: a statement of fact is simply a statement 
>> that *can* be verified).
>
> I am going to have to disagree, I think what you are calling a
> statement of fact, is actually a claim. A statement is simply a
> piece of communication. So if you state a belief, you are simply
> communicating that belief's existence. So a statement of fact is
> simply the communication that the fact exists.

Well, you can disagree but it doesn't change the fact that what I 
meant and what you're saying are two different things. With this 
knowledge you can now infer that you are putting forth effort to 
intentionally misunderstand me despite me trying to clarify that 
there is a difference, which isn't productive.

> In reality you can never actually state a fact because you can
> only ever believe a fact is true. It comes down to the
> philosophical problem of "I think therefore I am", which
> basically says that the only thing that your mind can PROVE 100%
> is that you are thinking.
>
> You can state a belief, but to anyone else hearing that
> statement, it will be a claim. Basicly is comes down to this...
>
> *A claim is something that can be true or false
>
> *A belief is a claim that is true in the believer's mind, but if
> stated becomes a claim due to that possibility that the
> believer's is in error
>
> *A fact is something that is always true
>
> That is why you can have true statements and false statements, 
> it
> is not that the statement is self is true or false, but that the
> claim that is being stated is true or false.

Frankly, it seems we've regressed back to making up definitions 
for words and phrases that are well-defined and those 
well-defined meanings contradict what you're trying to suggest. 
That's not going to help you understand why I think assert makes 
sense given the real definition of an assertion.

> It is not a matter of the compiler trying to determine if you
> meant to write what you did or not(there is no way it can). It 
> is
> a matter of the compiler determining if what you wrote is what 
> it
> considers to be correct input. If you try to compile
> "SDA@#$!$SDF#$T#", the compiler has no way of knowing if you
> meant to write that or not, but it is still allowed to reject
> that.

Of course, but it must reject that because it couldn't possibly 
understand that. Furthermore, most of the things in compilers 
that are disprovable at compile time are disproven at compile 
time. Those things which cannot be disproven at compile time 
(see: halting problem) cannot be rejected. Hence, if statements 
and asserts, and why type-check failures result in a failed 
compilation.

> Because if the compiler actually checks the claim then it can
> optimize on it, but if the compiler does not check then it can
> not know its true and can not optimize.

But it doesn't need to check because that's not what assert means 
to do. You're focusing too much on the "checking" part which has 
nothing to do with the actual English definition of assert (which 
is my point for why it makes sense for assert to do what it 
does). A runtime check is a "nice thing to have" (it makes 
asserts more useful, ultimately), but it seems completely 
orthogonal to what assert means in this case considering the 
definition of assert.

> I think a point that needs to be addressed is that there is a
> difference between a program being defined incorrectly and a
> program being undefined.
>
> If the programmer defines his program incorrectly, then yes, you
> are correct in that the compiler has no choice but to still take
> the incorrect definition.
> The program is still defined in a way the compiler understands,
> its just not what the programmer was trying to say.
>
> But, if a program is undefined, then the compiler does not know
> what to do, which in how compilers are implemented means the
> compiler can literally do anything it wants.
>
> Typing "while" instead of "if" might be an incorrect definition
> of the program that the programer was trying to create, but is 
> is
> still a valid program definition(just not the one the programmer
> wanted).
>
> On the other hand, having contradicting asserts(with your
> interpretation of assert) is not an incorrectly defined program,
> but an undefined program because it simply does not make sense.

OK, but I see these as being much more similar conceptually than 
you're giving them credit. Despite "undefined behavior" occurring 
when an assertion fails, it doesn't actually mean that you can't 
reason about what can occur, just that there's no required 
definition for what will occur (that's why it's called 
"undefined"). That is the two interpretations of a D program are 
accepted by the spec:

```
assert(x != 1);
//... code that doesn't have any effect on x
if(x == 1) { /* ... */ }
```

```
assert(x != 1);
//... code that doesn't have any effect on x
```

The "undefined behavior" is that it allows these two to be 
equivalent programs. You can reason about why the program isn't 
doing what you want, so it's not that it's an "undefined 
program", just that two (or more) definitions of a program are 
equivalent as far as the D spec is concerned.

You don't know which one you can get, but you do know that they 
are equivalent (because of your assertion).

Actually, what's really weird is the fact that no one would be 
complaining if asserts were always checked, even though the above 
is exactly what you could get by the optimizer. The real strange 
thing is that you'd want the removal of checked asserts to change 
the way your program can be optimized.