if(arr) now a warning

[deadalnix via Digitalmars-d]

On Thursday, 30 April 2015 at 16:49:59 UTC, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message 
> news:mhtggg$26b5$1 at digitalmars.com...
>
>> I think we need to stop here. I'll make the PR today for 
>> reverting this language change. We can't handle D like a 
>> semester science project, because for as long as we do we 
>> won't have credibility.
>
>> This trickle of teeny-bit breaking changes for the sake of 
>> touted benefits must stop.
>
> This breaking change prevents hard-to-find bugs.  The fact that 
> you needed to make trivial changes to 39 places in 
> std.allocator doesn't negate this.

I can second this. The code is often not test in an apropriate 
manner.

Let's say you have some code that goes as:

auto foo(T[] ts) {
     if (ts) {
         // ...
     } else {
         // ...
     }
}

Now test :

unitest {
     assert(foo([1, 2, 3]) == ...);
     assert(foo([]) == ...);
}

All tests passes, the code looks correct, but in fact it is going 
to break when foo is called with a drained range, or some slicing 
tat happen to have 0 elements.

That makes for very hard to find bugs.

The current behavior is also inconsistent with general slice 
behavior (which distinguish between identity and value).

People are not making stuff up here. The current behavior is bug 
prone AND inconsistent. And yes, I'm working on SDC's GC, so I'm 
aware that there is code that specifically care about the 
address. This is what the is operator is for.