assert(obj) is an atrocity

[Timon Gehr]

On 11/09/2011 01:18 AM, Martin Nowak wrote:
> On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
> <xtzgzorex at gmail.com> wrote:
>
>> Hi,
>>
>> As the title suggests, I'm going to be rather blunt about this.
>> assert(obj) testing the invariant *without* doing a null check is
>> insane for the following reasons:
>>
>> 1) It is not what a user expects. It is *unintuitive*.
>> 2) assert(!obj) does an is-null check. assert(obj) is a completely
>> broken opposite of this.
>> 3) No AssertError is thrown, which is the entire point of the built-in
>> assert().
>> 4) The few added instructions for the null check hardly matter in a
>> *debug* build of all things.
>>
>> I don't mind assert(obj) testing the invariant of obj. In fact, that
>> very much makes sense. But please, please, *please* check the object
>> for null first. This is a random inconsistency in the language with no
>> other justification than "seg faults are convenient in a debugger". By
>> the same logic, we might as well not have array bounds checks.
>> However, the state of things is that array bounds checks are emitted
>> by default and users can disable them for e.g. a release build. I
>> don't see why this case is any different.
>>
>> - Alex
>
> It does check for null.
> Only it's a runtime support function (_d_invariant) and druntime is likely
> compiled without assertions. Are you really suggesting to add a null
> check before
> every method call?
>
> martin

No, he is suggesting to add a null check for assert(objref);, a 
construct that *looks* as if it was a null check, but does something 
almost unrelated.