On Monday, April 01, 2013 23:44:43 Timothee Cour wrote:
> can we officially use
> 
> assert(a);
> 
> instead of
> 
> assert(a !is null);
> 
> (likewise with if(...))
> 
> It seems to compile and work just fine, and is shorter.

That depends on what a is. If it's an AA as in the OP, then yes, they should be the same. The same goes for a pointers to built-in types and arrays, but for classes and pointers to structs, assert(a) checks for null and then calls the class' invariant rather than just checking for null. However, the invariant does not get called for if statements.

- Jonathan M Davis

thanks I didn't know... must've been buried in the specs somewhere...

On Tue, Apr 2, 2013 at 12:10 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Monday, April 01, 2013 23:44:43 Timothee Cour wrote:
>> can we officially use
>>
>> assert(a);
>>
>> instead of
>>
>> assert(a !is null);
>>
>> (likewise with if(...))
>>
>> It seems to compile and work just fine, and is shorter.
>
> That depends on what a is. If it's an AA as in the OP, then yes, they should be the same. The same goes for a pointers to built-in types and arrays, but for classes and pointers to structs, assert(a) checks for null and then calls the class' invariant rather than just checking for null. However, the invariant does not get called for if statements.
>
> - Jonathan M Davis

On Tue, 02 Apr 2013 01:22:26 -0400, Maxim Fomin <maxim@maxim-fomin.ru> wrote:

> On Monday, 1 April 2013 at 23:56:08 UTC, Steven Schveighoffer wrote:
>> No, AA's are not classes (which BTW have had that problem fixed), they are pImpl structs.  The equals operator should check for null before comparing the contents.  It is a valid bug.
>>
>> -Steve
>
> This argument can be applied to classes too. I think it would be better to reject such code like in case with classes.

If you are saying you think AA's should reject the code when comparing to null, then I don't agree.  An AA is a struct, and a struct lives on the stack.  It would be near impossible to make this work without arbitrary compiler help, and I don't see a reason to specifically add this.  It's just as easy to check for null in opEquals.

With classes there was NO way to intercept the comparison before the dereference, so the banning of == null was warranted (that situation has changed now that opEquals is a global runtime function, so this requirement is somewhat moot).

-Steve