Acces Violation: assert with null instance

[Frits van Bommel]

Sean Kelly wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> It does check if it's null. That's how the access violation 
>>>> exception gets thrown.
>>>
>>> But that's generated by the hardware, isn't it?
>>
>> Yes.
>>
>>> Shouldn't assert explicitly check whether c is null before calling 
>>> its invariant?
>>
>> Why, if the hardware does it for you (without extra bloat)?
> 
> Just so a file and line number are available.  Though someone mentioned 
> the code already does something like "assert(obj); obj.invariant();" and 
> the problem here was that it was a release build?  If this is the case 
> I'm fine with the current behavior.  I really only care about this sort 
> of thing if asserts are enabled.

Yes, an assert(o !is null) is performed. But it's performed *inside* 
_d_invariant, which is part of Phobos. And since Phobos is only 
distributed as a release build, that means the assert is off by default 
_even if *your* program has asserts enabled_. You need to recompile 
Phobos to change this behavior. This is bad.

Perhaps that assert should just be converted to an "if (!o) 
_d_assert(__FILE__, __LINE__)" since _d_invariant will (presumably) only 
be called if the application has assertions enabled?