if(arr) now a warning

[Steven Schveighoffer via Digitalmars-d]

On 4/29/15 11:14 PM, Iain Buclaw via Digitalmars-d wrote:
> On 30 April 2015 at 04:41, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 4/29/15 4:29 AM, Iain Buclaw via Digitalmars-d wrote:
>>>
>>> On 29 April 2015 at 06:38, Steven Schveighoffer via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>>>
>>>> FYI, Andrei and Walter are reversing this change barring any new evidence
>>>> it's helpful to people. Please speak up if you disagree.
>>>>
>>>>
>>>> https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912
>>>>
>>>
>>> I disagree, and I would extend my thoughts to say that I don't think
>>> that the change is enough.  We should also be warning on delegates and
>>> associative arrays too!
>>>
>>> if (arr)  // Implicitly converted to (arr.ptr | arr.length) != 0
>>
>> if(arr) simply means if(arr.ptr) != 0. Length does not come into play.
>>
>
> https://github.com/D-Programming-Language/dlang.org/pull/981#commitcomment-10918439
>
> The two mov's followed by an 'or' suspiciously look like (.ptr | .length) to me.

Huh. I guess you are right. I never thought to test that, but it does 
indeed mean that.

I suppose for all intents and purposes, arrays with nonzero length and 
null pointer are so rare it may as well just be testing if the pointer 
is non-null.

>
>>> if (dg)  // Implicitly converted to (dg.ptr | dg.funcptr) != 0
>>
>>
>> I don't know if I've ever expected that, you sure that's true? I would
>> actually expect if(dg) to be equivalent to if(dg.funcptr). I have no idea
>> how a dg would have a null pointer but valid funcptr.
>>
>
> Yes, it does (it emits the same assembly as arrays).

OK, but in this case I think dg.funcptr is what we want to test, the 
dg.ptr isn't really relevant. And I don't think you'd find a case where 
dg.funcptr is null but dg.ptr isn't.

>>> if (aa)  // Implicitly converted to (aa.ptr != null)
>>
>>
>> This is easily fixed when we fix aa to be a library type. We don't need
>> compiler help to fix this issue (we do need compiler help to remove AA
>> specialty code from the compiler, but once it's out, we can fix this without
>> effort).
>>
>
> It's still annoying to have to special-case non-scalar types in
> boolean contexts.  The front-end should do this lowering. :-)

None of these things really affect me, I never use if(arr) or if(aa), 
because I'm too skeptical of what they convey, and have been burned by 
those in the past. And if(dg) doesn't seem to have issues with how it's 
implemented.

If it was in a code review, I'd reject such usages.

I personally don't think if(arr) or if(aa) should EVER compile with any 
kind of lowering. The meaning is too non-obvious.

-Steve