Am 01.08.2014 05:17, schrieb Walter Bright:
Frankly, it never occurred to me that it wasn't obvious. When something
is ASSERTED to be true, then it is available to the optimizer. After
all, that is what optimizers do - rewrite code into a mathematically
equivalent form that is provably the same (but cheaper to compute). Its
inputs are things that are known to be true.
For example, if a piece of code ASSERTS that x is 3, thereafter the
optimizer knows that x must be 3. After all, if the optimizer encounters:
x = 3;
do I need to then add a note saying the optimizer can now make use of
that fact afterwards? The use of "assert" is a very strong word, it is
not "maybe" or "possibly" or "sometimes" or "sort of".
When you write:
assert(x == 3);
then at that point, if x is not 3, then the program is irretrievably,
irredeemably, undeniably broken, and the default action is that the
program is terminated.
The idea expressed here by more than one that this is not the case in
their code is astonishing to me.
Well, this all sounds sane and makes sense in a way.
The thing is, I never considered assert() to mean this up to now, which
is probably influenced by the following reasons:
In programming I've always encountered assert() in an "check if
assertions are enabled/you're in debug mode, do nothing otherwise" way
(that's what C, C++, Java and Python do).
In unit tests the "checks" are also often called assertions.
I'm not a native speaker..
.. but even if I were: words used for constructs/function-names/... in
programming often don't 100% match their "real" meaning (as used in
human communication)[1] - why should it be different for assert(),
especially when not implemented/used like that in many popular
programming languages?
Cheers,
Daniel
[1] Examples for "spoken meaning" vs "programming lingo":
* or (in spoken language often used meaning "xor" - "do you want milk or
sugar with your coffee?" - "true" - "wtf?")
* class (has many meanings in language, I guess none 100% matches the
use in programming)
* peek()/poke() (which thankfully get more descriptive names in D)
* heap (the data structure has some kind of order, real life heaps are
just chaotic piles of stuff)
* iota (just some greek letter, /maybe/ "a little bit" in spoken
language, in some programming languages/std libs it means "sequence of
consecutive numbers" - wtf?)
* exception (in real life not something that is "thrown around")
