assert(obj) is an atrocity

[Davidson Corry]

I don't get it -- why is this even necessary? Please don't answer here. 
Swing over to D.learn, where I am starting an "assert(obj) is a mystery" 
thread...

...because answers that start with "because..." belong in a "learn" 
newsgroup.

Thanks in advance.

-- Davidson



On 11/8/2011 2:35 PM, Alex Rønne Petersen 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