checkedint call removal

Chris Cain via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 1 22:07:56 PDT 2014


On Saturday, 2 August 2014 at 04:40:53 UTC, Tofu Ninja wrote:
> I don't know... maybe I can try to explain what he is trying to
> say.
> Correct me if I am wrong in either of your interpretations of
> assert.
>
> Your claim is that an assertion is a promise, by the person
> asserting, that something is always true. Meaning if you assert
> something, the compiler will interpret it to always be true. In
> essence the compiler will interpret your promise(as the
> programmer) as a never changing fact that can be used for
> optimizations.

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). An intrinsic part of programming is that whatever 
you write is what you intend to write (that is, it must assume 
that you aren't incorrect because it otherwise couldn't compile 
the program ... or it'd have to ask you for every line to "sign 
off" that it's what you intended). The obvious conclusion is that 
you must "promise" that you know what you're doing.

As the human and good programmer, it seems that you wouldn't want 
to assume you're correct, but the compiler/programming language 
itself has no option but to assume you meant an if statement 
there or a function call here, and that you intended these 
particular arguments to be passed in this particular order. It 
also assume your assertions are what you meant them to be. The 
fact that they are checked is a bonus feature (which is really 
where the confusion behind assertions lies, as it was for me... 
I, like you, thought that assertions MUST be verified and 
checked, but that turns out to not be what that meant at all).

> His claim is that an assertion is a claim by the person
> asserting. That claim has not been proven to be true or false.
> Meaning that as a claim, the compiler can't do anything with 
> that
> information alone. The compiler can try to check if the claim is
> true and if it is, use that information to optimize. But if it 
> is
> not checked it is merely a claim with no backing, and as such,
> nothing can be done with it.

Of course, I can understand that interpretation. But at the same 
time, why would you write something and expect a compiler to do 
nothing with it? Is there any other construct in the language 
that does that? Even noops in ASM which literally mean "do 
nothing" actually have an effect on the intended meaning of a 
program.

>
> ...
>
> Ok that was my interpretation of both of your interpretations. I
> hope I didn't misinterpret.
>
> Personally I side with the argument that assert is a claim which
> I believe is closer to the actual meaning of the word assert and
> closer to how programmers use assert now.
>
> If you look at the google definition of assert...
>
> "state a fact or belief confidently and forcefully."
>
> You will see that it says an assertion is a statement of a "fact
> or belief". The "confidently and forcefully" portion of the
> definition is just describing the attitude of the asserter, so 
> in
> this context is not relevant. That means that the speaker can 
> use
> an assertion to state either a fact or a belief(I think in this
> context a belief is sufficiently close to a claim, both could be
> true or false). As the person being spoken to, there is no way 
> to
> know if the speaker is asserting a fact or a belief. This means
> that as the person being spoken to, you have no choice but to
> come to the conclusion that what is being asserted could be
> either of the two and thus could either be true or false.
>
> In the context of a programmer and a compiler, the programmer is
> the speaker and the compiler is the thing being spoken to. This
> means that if the programmer asserts something the compiler has
> no choice but to interpret what is being asserted could either 
> be
> true or false.
>
> Now you could say that the compiler implicitly trusts the
> programmer and as such takes all assertions as fact, but I
> believe that is a mistake on the compilers part. If the compiler
> implicitly trusted the programmer, there would be no warnings,
> and type checking ... ect. You could say that the compiler only
> implicitly trusts the programmer in the case of assert, but I
> still believe this to be a mistake on the compilers part.

I see it the exact opposite way. I see it as the compiler is 
helpful and will do as much proving as it can, but ultimately it 
must always logically put if statements in where you want them 
and function calls in where you want them. Technically, it takes 
some liberties with optimizations because it has good reason to 
believe that the two interpretations are equivalent. That said, 
when we pass `-O` to the compiler, we're commanding it to do 
that... so... *shrug*

Thus when you assert something is true and the compiler can't 
immediately disprove you, it must follow what you say. FWIW, I 
feel that something like this should fail compilations:

```
int x = 1;
assert(x != 1);
```

because the compiler could, in fact, disprove you at compile 
time. That said, it's not a scalable approach because there 
exists too many programs that you cannot prove the output of. 
Otherwise, if it can't immediately disprove what you say (by type 
checking, for instance), then it has no choice but to do what you 
say, even if you're wrong. Even if you do `x1 == x2 && y1 == x2` 
in a conditional somewhere, it can't/won't take liberties to 
"correct it" to `x1 == x2 && y1 == y2`. But if x1 is a 
FloatMeters and x2 is a FloatMiles, I would expect it to disprove 
that it's a correct comparison (unless you make statements 
suggesting that this is what you really mean, of course). But 
then again, I refer to the above where obviously illogical things 
should fail to compile as well. But once it compiles, I expect 
that it does what I say even if what I say is wrong.


More information about the Digitalmars-d mailing list