assert(obj) is an atrocity

[Alex Rønne Petersen]

On 09-11-2011 06:23, Davidson Corry wrote:
> 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
>

This has nothing to do with learning. This entire thread is a language 
design counter-argument.

- Alex