assert(obj) is an atrocity

[Timon Gehr]

On 11/09/2011 01:21 AM, Timon Gehr wrote:
> 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.

BTW, the number of occurrences of assert(objref && 1); in my code is huge.