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

[Georg Wrede]

Walter Bright wrote:
> Kristian Kilpi wrote:
> 
>> The problem is that
>>
>>   assert(obj);
>>
>> does not first check if 'obj' is null.
> 
> Yes it does, it's just that the hardware does the check, and gives you a 
>  seg fault exception if it is null.


That sounds like "this is not negotiable".


IMHO, assert(o) should mean check existence. When it now doesn't, people 
write if(o !is null) all over the place, *simply* because of the 
symmetry. It's easier to remember one single idiom for the test, rather 
than having to first learn and then to remember where to use which. That 
litters code, is cumbersome, and is more verbose than needed, in a 
Practical language.

Having assert(o) mean assert(o.integrity()), or whatever unobvious, 
saves ink, no question. How much work it saves when we ordinary mortals 
start using it, is another question.

Ink savings are not an argument when there's at most a couple of such 
asserts in an entire application. But, where ink savings would be an 
argument, i.e. lots of assert(o)s in the source tree, it is unusable 
since segfaults don't tell the *source line number*. Thus, again no ink 
savings.

The current assert behavior is unexpected, and it surprises one exactly 
when one least needs it: when Boss says you gotta fix the bugs, tonight.


At any rate, I suspect D programmers are hardly relying on the current 
behavior, simply because it smells like it can change any day. So a 
careful coder would write assert(o.checkInvariants()) anyhow.

Besides, the object won't have any checkInvariants() to begin with, 
unless the coder is one of the careful ones!

---

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?

---

Unexpected behavior introduces exceptions (as in normal English), that 
you must remember, into the language. They immediately make the coder's 
burde heavier, and later stand in the way of future improvements or changes.

This assert thing certainly isn't worth the current and future cost, IMHO.