Thoughts on some code breakage with 2.074

[Steven Schveighoffer via Digitalmars-d]

On 5/10/17 2:49 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
>> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
>>  > I even appreciate breakages that eventually force me to write more
>>  >
>>  > readable code!  A not-so-recent example:
>>  >    /* Used to work, oh, I forget which version now, but it used to
>>  >
>>  >     * work: */
>>  >
>>  >    MyType* ptr = ...;
>>  >    if (someCondition && ptr) { ... }
>>  >
>>  > After upgrading the compiler, I get a warning that using a pointer as a
>>  > condition is deprecated.  At first I was mildly annoyed... but then to
>>  >
>>  > make the warning go away, I wrote this instead:
>>  >    /* Look, ma! Self-documenting, readable code! */
>>  >    MyType* ptr = ...;
>>  >    if (someCondition && ptr !is null) { ... }
>>
>> Can you show an example please. I don't see this being required by
>> 2.074.0 (compiled with -w -de).
>
> I think that that's the one that Andrei and Vladimir didn't like, because
> they actually used the conversion to bool correctly in their code a bunch
> (whereas most everyone else thought that it was too error prone), and the
> deprecation ended up being removed.

I think that was the if(array) fiasco.

I don't ever remember if(ptr) being deprecated. In fact, I'd go as far 
as saying that maybe H.S. Teoh misremembers the array thing as pointers.

The biggest reason is that a huge useful pattern with this is:

if(auto x = key in someAA)
{
    // use *x without more hash lookup costs.
}

I can't imagine anyone attempted to force this to break without a loud 
backlash. I think if(ptr) is mostly universally understood to mean the 
pointer is not null.

-Steve