debugger blues

[cy via Digitalmars-d]

You know what I really want? I want to disable package:/private: 
access entirely! Since GDB is useless, I can't write assertions 
to compare the structure of two objects, without going into that 
3000 lines of code and writing a function to compare them in that 
particular fashion. Not being allowed to turn those accesses into 
warnings, or temporarily disabling them, seems a bit spiteful. It 
takes a lot of hubris for a programmer to decide that nobody else 
will ever want to do something with their code, that they didn't 
themselves anticipate.

On Friday, 25 March 2016 at 09:30:37 UTC, Vladimir Panteleev 
wrote:

> "null this" is the error I'm talking about. It is coming from 
> the object invariant. It's not caused by a segmentation fault 
> caused by accessing a member.

It still happily allows me to pass around that null pointer as if 
it were a real object, and call member functions on that null 
pointer. It's only when it tries to access a member variable that 
it raises the error. I'm of the opinion that null should be 
categorically different from a pointer to a class or struct. 
Because when I get "null this" I have no general way to tell 
where that null pointer came from, and just have to eyeball the 
code and trace back to guess where it might have returned an 
unexpected null.

Segfaulting on a null this would be totally terrible, but 
erroring out on "null this" is still fail-slow.