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
