checkedint call removal

[Tofu Ninja via Digitalmars-d]

On Saturday, 2 August 2014 at 06:35:33 UTC, Chris Cain wrote:

> 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

Yes.... I disagreed with you... so yes I am saying something
different. What else is "disagreement" supposed to mean?

> 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.

I understood what you said, I just disagreed with it. Are you
saying I can't disagree???

> 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.

None of these words or phrases are well defined.... if assert was
well defined we would not be talking now....

I understand your argument, I just don't think it is correct.
Particularly I don't agree that your interpretation of assert
more closely matches the real meaning of assert. Let me reiterate
why...

When something is asserted, there is the asserter(the person
making the assertion) and the asserti(s)(the person/people that
are hearing the assertion). Given that any thing that is asserted
can either be true or false, the asserti has no choice but to
conclude that what is being asserted may or may not be true.

In the context of the programmer(asserter) and the
compiler(asserti). The programer is making an assertion that the
compiler must conclude to be either true or false. Because it
does not know if it is true or not, the only time it is
acceptable for the compiler to optimize as if it is true is to
actually check if it is true.

> 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.

The point is that without the check, the assertion is neither
proven or disproven. If the compiler receives bad
input(incorrectly defined input is not bad input), then it knows
it is bad, but the compiler has no way of knowing if an assertion
is good or bad.

If the compiler receives two asserts that can not both be true,
then there is no way it can know what to do, there is no
resolution. But if the compiler is not smart enough to recognize
that they are contradictory then is just compiled an uncompilable
program....

> 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).

I can understand why you think that, I just don't agree. I don't
agree that an assertion in the english language means that
something will be true, I interpret it as a claim that something
may or may not be true.

> 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.


> 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
> ```

That is not an undefined program.... the code you just presented
was completely defined. An an example of an undefined program
with respect to assert is as follows.

assert(x==1);
assert(y==2);


Lets say the compiler was not smart enough to see that these
could not both be true. There is no way the compiler can produce
and thing that is correct because they both cannot be true. There
will always be sets of conditions that the compiler can not prove
to be contradictory(because of the halting problem) but that are.
That is an undefined program...

> The "undefined behavior" is that it allows these two to be 
> equivalent programs.

That is not the undefined behavior

> 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.

That is actually the point, no one would be complaining because
there would be nothing wrong. There would be no chance of
undefined behavior. If the check is always there then the program
will always know that after the assert the condition is true and
would be free to do any optimizations it wants. The undefined
behavior occurs when you optimized as if they are true but do not
check.