This code:

   void main ()
   {
       Object foo;
       assert (foo);
   }

Compiles but has an "Error: Access Violation" on execution.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bg0r8t$2jh7$1@digitaldaemon.com...
> This code:
>
>     void main ()
>     {
>         Object foo;
>         assert (foo);
>     }
>
> Compiles but has an "Error: Access Violation" on execution.

Correct, since foo is null.

Walter wrote:

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bg0r8t$2jh7$1@digitaldaemon.com...
> 
>>This code:
>>
>>    void main ()
>>    {
>>        Object foo;
>>        assert (foo);
>>    }
>>
>>Compiles but has an "Error: Access Violation" on execution.
> 
> 
> Correct, since foo is null.

Not correct, man.  Assert is not behaving here in the same way as if, for, while, or the trinary operator.  This test is implicitly defined as being equivalent to "foo !== null" in the Expressions/Cast Expressions section, and the AssertExpression definition gives no indication that it alters casting semantics for its special case.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bg0vpb$2om0$1@digitaldaemon.com...
> Walter wrote:
>
> > "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bg0r8t$2jh7$1@digitaldaemon.com...
> >
> >>This code:
> >>
> >>    void main ()
> >>    {
> >>        Object foo;
> >>        assert (foo);
> >>    }
> >>
> >>Compiles but has an "Error: Access Violation" on execution.
> >
> >
> > Correct, since foo is null.
>
> Not correct, man.  Assert is not behaving here in the same way as if, for, while, or the trinary operator.  This test is implicitly defined as being equivalent to "foo !== null" in the Expressions/Cast Expressions section, and the AssertExpression definition gives no indication that it alters casting semantics for its special case.

So you argue it should give an AssertException rather than an access violation exception?

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bg0vpb$2om0$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>
>>>"Burton Radons" <loth@users.sourceforge.net> wrote in message
>>>news:bg0r8t$2jh7$1@digitaldaemon.com...
>>>
>>>
>>>>This code:
>>>>
>>>>   void main ()
>>>>   {
>>>>       Object foo;
>>>>       assert (foo);
>>>>   }
>>>>
>>>>Compiles but has an "Error: Access Violation" on execution.
>>>
>>>
>>>Correct, since foo is null.
>>
>>Not correct, man.  Assert is not behaving here in the same way as if,
>>for, while, or the trinary operator.  This test is implicitly defined as
>>being equivalent to "foo !== null" in the Expressions/Cast Expressions
>>section, and the AssertExpression definition gives no indication that it
>>alters casting semantics for its special case.
> 
> 
> So you argue it should give an AssertException rather than an access
> violation exception?

That's certainly what I expected it to do when I read the code!

Russ

Walter wrote:

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bg0vpb$2om0$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>
>>>"Burton Radons" <loth@users.sourceforge.net> wrote in message
>>>news:bg0r8t$2jh7$1@digitaldaemon.com...
>>>
>>>
>>>>This code:
>>>>
>>>>   void main ()
>>>>   {
>>>>       Object foo;
>>>>       assert (foo);
>>>>   }
>>>>
>>>>Compiles but has an "Error: Access Violation" on execution.
>>>
>>>
>>>Correct, since foo is null.
>>
>>Not correct, man.  Assert is not behaving here in the same way as if,
>>for, while, or the trinary operator.  This test is implicitly defined as
>>being equivalent to "foo !== null" in the Expressions/Cast Expressions
>>section, and the AssertExpression definition gives no indication that it
>>alters casting semantics for its special case.
> 
> 
> So you argue it should give an AssertException rather than an access
> violation exception?

I argue that assert should be implemented in a way consistent with the rest of the logic statements.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bg15ra$2ukf$1@digitaldaemon.com...
> > So you argue it should give an AssertException rather than an access violation exception?
> That's certainly what I expected it to do when I read the code!

I've had a similar long discussion with Matthew about things like this. The idea is that accessing a null pointer generates a hardware exception. The D runtime library turns the hardware exception into a D exception, accessible with a catch statement. If those exceptions are not caught in user code, they're caught by phobos/dmain2.d and the associated message is printed out, in this case, "Access Violation".

Hardware exceptions are not program crashes any more than software exceptions are.

The nice thing about hardware exceptions is you get them for 'free' - no code bloat, no runtime performance penalty. So why make an extra software test for a null pointer and generate an exception? Let the hardware do it for free.

Walter wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:bg15ra$2ukf$1@digitaldaemon.com...
> 
>>>So you argue it should give an AssertException rather than an access
>>>violation exception?
>>
>>That's certainly what I expected it to do when I read the code!
> 
> 
> I've had a similar long discussion with Matthew about things like this. The
> idea is that accessing a null pointer generates a hardware exception. The D
> runtime library turns the hardware exception into a D exception, accessible
> with a catch statement. If those exceptions are not caught in user code,
> they're caught by phobos/dmain2.d and the associated message is printed out,
> in this case, "Access Violation".
> 
> Hardware exceptions are not program crashes any more than software
> exceptions are.
> 
> The nice thing about hardware exceptions is you get them for 'free' - no
> code bloat, no runtime performance penalty. So why make an extra software
> test for a null pointer and generate an exception? Let the hardware do it
> for free.

In what way do you interpret the assert such that it would cause a hardware exception?  The only way to cause a hardware exception is to dereference the null pointer (reference, sorry).  Why would you do that in an assert?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bh62vo$21bt$1@digitaldaemon.com...
> Walter wrote:
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bg15ra$2ukf$1@digitaldaemon.com...
> >>>So you argue it should give an AssertException rather than an access violation exception?
> >>That's certainly what I expected it to do when I read the code!
> > I've had a similar long discussion with Matthew about things like this.
The
> > idea is that accessing a null pointer generates a hardware exception.
The D
> > runtime library turns the hardware exception into a D exception,
accessible
> > with a catch statement. If those exceptions are not caught in user code, they're caught by phobos/dmain2.d and the associated message is printed
out,
> > in this case, "Access Violation".
> >
> > Hardware exceptions are not program crashes any more than software exceptions are.
> >
> > The nice thing about hardware exceptions is you get them for 'free' - no code bloat, no runtime performance penalty. So why make an extra
software
> > test for a null pointer and generate an exception? Let the hardware do
it
> > for free.
>
> In what way do you interpret the assert such that it would cause a hardware exception?  The only way to cause a hardware exception is to dereference the null pointer (reference, sorry).  Why would you do that in an assert?

An assert on an object reference calls the invariant for that object. If the reference is null, it'll gp fault.

Walter wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:bh62vo$21bt$1@digitaldaemon.com...
> 
>>In what way do you interpret the assert such that it would cause a
>>hardware exception?  The only way to cause a hardware exception is to
>>dereference the null pointer (reference, sorry).  Why would you do that
>>in an assert?
> 
> 
> An assert on an object reference calls the invariant for that object. If the
> reference is null, it'll gp fault.

Ok, that sounds reasonable.  But is there any reason why it shouldn't check against null first?  We are in debug mode, so performance isn't (as much of) an issue.