LONG Re: Suggestion: "fix" assert(obj)

[Georg Wrede]

(( Top-posting makes it harder to follow for the rest of us...))

Tristam MacDonald wrote:
> Georg Wrede Wrote:
(because of top-posting, watch out for who wrote what)


> Actually, I would expect it to be a no-op, since the fewer conditions
> that must be satisfied, the less likely the assert is to fail. Think
> of a nullary logic ops in scheme, etc. (and, or)...

See way below.

---
         if(){writefln("foo");}

hardly produces a no-op. It gives "expression expected, not ')'". And it 
should.

(Academically:) if the above error was not errored, then the next thing 
would be to return false, because the Thruth of Nothing is False.

>> What would your reaction be if you find the following line inside a
>> method?
>> 
>> assert();
>> 
>> What's the first thought? Apart from that it must cause a compiler
>> error since there's no expression at all. What would you expect it
>> to do? If I told you we've fixed gdc so that an empty assert within
>> a method causes immediate assertion of the current instance's
>> consistency, would you approve?

So, logically, assert() should fail.

Nothing (as in (), ) equals false. Thus, it should fail. An assertion 
fails (even by the grammar in Natural languages, as in English) when it 
does not produce something true. (Assert Victim has pulse. He has, ok. 
He has no pulse: dead, assertion failed.)

assert(null)       should produce false.
assert(0)          should produce false.
assert(i)          should produce true if i is non-null, else false.
assert(o)          should produce true if o exists, false otherwise.

Few expect, and even fewer hope that testing for existence (as in 
assert(o)) actually decides to run some canonicalized method of o "to 
check if the instance is happy".