checkedint call removal

Tofu Ninja via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 1 21:40:51 PDT 2014


On Saturday, 2 August 2014 at 02:42:50 UTC, Chris Cain wrote:
> On Saturday, 2 August 2014 at 02:32:45 UTC, Timon Gehr wrote:
>> On 08/02/2014 04:28 AM, Chris Cain wrote:
>>> ...
>>
>> I retract my apology.
>
> Of course. The worst curse I could wish upon you is that you 
> stick to your guns. So stick to your guns, my friend. :-)

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.

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.

...

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.


More information about the Digitalmars-d mailing list