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@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@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
