Thoughts on some code breakage with 2.074

[Patrick Schluter via Digitalmars-d]

On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote:
> On 05/10/2017 11:49 AM, 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:
>
> >>  > After upgrading the compiler, I get a warning that using
> a pointer as a
> >>  > condition is deprecated.
>
> > 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.
> >
> > - Jonathan M Davis
>
> Bummer for H. S. Teoh I guess... :/
>
> Although I prefer explicit over implicit in most cases, I've 
> never graduated from if(p) and still using it happily. :)
>
Yes, me too (in C). It is conceptually imho ok to use it that way 
as a pointer does have a boolean semantic, either it is a valid 
pointer or it is not. The value of the pointer itself is only in 
special cases relevant (cases in which they have to be converted 
to an integral type anyway) and is in any case extremely machine 
dependent.
One can even make the case that checking "ptr !is null" or in C 
"ptr != 0" is inconsistent as it is the only operation where the 
value of a pointer is used, which is, at least for C a source of 
confusion. The 0 value in a pointer context will not necessarily 
compile to a 0 value in the generated assembly. Some machines 
have null ptrs that are not represented by 0 bits integral values 
and the C standard has to take these (granted obsolete) into 
account.