On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
<xtzgzo...@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
