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

[Georg Wrede]

Bill Baxter wrote:
> Georg Wrede wrote:
>> 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.
>> 
>> Asserts were INVENTED to *avoid segfaults*.
> 
> What I find odd is that Walter often argues that things in D that
> *look* like C++ should *act* like C++ as much as possible.

He should. This is a C family language, designed to woo the C(++) crowd
out of their misery. So, things that "look" the same, should act
unsurprisingly. And things that don't act like those folks expect,
should look something diferent.

> As a C++ user I continually find it bizarre and hard to remember that
> assert() has these special cases.

Exactly my point.

> There's also something unusual about assert(0), too.  It stays
> enabled in release mode.  And it's not a seg fault.  But assert on a
> 0 that happens to have a certain type is.  Odd.  Not making my life 
> any easier I don't think.  I'm sure if I keep poking my brain and 
> telling it "assert(object) is different!", I'll get it internalized 
> eventually, but I really just don't find the "feature" of running 
> invariants all that compelling.

Precisely why I got my blood pressure up with this.

Actually, this particular case doesn't bother me that much since I 
personally don't use asserts that much. Instead I use writefl(whatever) 
for my debugging, and either delete those lines when that particular bug 
is fixed, or leave them as comments. But I can imagine a whole lot of 
circumstances where it would be wise to leave the assertion in place. 
The most obvious example would probably be creating a library of 
red-black trees.

So, this is an issue that carries much _principal_ weight. If we don't 
close the door for mice right now, then we might as well leave the 
entire wall open. The end result five years from now won't be that 
different. (I've lived on the country side, I know.)

Currently, msg 54517, shows that the entire "assert show" is broken.

It might be argued that the whole concept of calling assert and having 
it sort out for itself whether there's a classInvariant method, is 
questionable. (In other threads folks have been dying for a compelling 
example for the need to have compile time introspection (as in, call 
this method if it exists or do something else reasonable instead). Well, 
here it is.)

Even if it weren't broken, the question is, should it at all be possible 
to simply call assert and have it _implicitly_ run methods in the object 
instance? Such would heavily change the semantics of assert, as compared 
with any other languages (read: people's expectations).