A confusing and dangerous "feature" of D was to treat the expression if(arr) as meaning if(arr.ptr).

Anyone coming from any number of other languages may think that if(arr) means "if arr has any elements". Typically one cares what is inside an array, not where it lives.

However, while checking to see if an array has elements is very similar to checking for a null pointer (obviously, a null pointer array should have no elements), it's not equivalent. Therefore, when attempting to fix this confusion, we had to disable the if(arr) check altogether. You must now specify what part of the array you care about, if(arr.ptr) or if(arr.length).

As usual with changes of this nature, there are differing opinions, and differing styles. I personally never use null as a special value for an array, but others do. They use if(arr) to actually mean if(arr.ptr). For these cases, the update will cause some amount of busywork changing these checks.

But when updating Phobos to comply with this change, we found several actual incorrect usages. So I think the change is worth it, and not much busywork. YMMV.

What do you think?

references:

https://issues.dlang.org/show_bug.cgi?id=4733
https://github.com/D-Programming-Language/dmd/pull/2885
https://github.com/D-Programming-Language/tools/pull/166

-Steve

Steven Schveighoffer:

> What do you think?

I asked for this fix almost five years ago, so I think it's about time :-)

Bye,
bearophile

On Thu, Apr 09, 2015 at 04:59:00PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> A confusing and dangerous "feature" of D was to treat the expression
> if(arr) as meaning if(arr.ptr).
[...]
> Therefore, when attempting to fix this confusion, we had to disable
> the if(arr) check altogether. You must now specify what part of the
> array you care about, if(arr.ptr) or if(arr.length).
[...]
> But when updating Phobos to comply with this change, we found several actual incorrect usages. So I think the change is worth it, and not much busywork.  YMMV.
[...]

I agree it's worth it. It's one of the very legitimate reasons for breaking code IMO. Or rather, to bring to the user's attention code that likely already contains latent bugs.

Sure some people will complain about it, but in the long run, I think they will come to appreciate the improved code correctness that this confers.

It's akin to a similar change sometime ago that made bare pointers in if-conditions illegal: writing `if (ptr && ...)` will cause the compiler to complain loudly. When this first got in, one of my projects broke, and I was rather annoyed at the time. However, when I got around to fixing it, I found that I had to write `if (ptr !is null && ...)` instead, which greatly clarifies the intent and readability of the code. Since then, I have come to appreciate this change.

So this gets a thumbs up from me.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.1388.1428620346.3111.digitalmars-d@puremagic.com...

> It's akin to a similar change sometime ago that made bare pointers in
> if-conditions illegal: writing `if (ptr && ...)` will cause the compiler
> to complain loudly. When this first got in, one of my projects broke,
> and I was rather annoyed at the time. However, when I got around to
> fixing it, I found that I had to write `if (ptr !is null && ...)`
> instead, which greatly clarifies the intent and readability of the code.
> Since then, I have come to appreciate this change.

Except that never happened.  Maybe you're thinking of comparing objects to null with ==? 

On Fri, Apr 10, 2015 at 01:01:48PM +1000, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.1388.1428620346.3111.digitalmars-d@puremagic.com...
> 
> >It's akin to a similar change sometime ago that made bare pointers in if-conditions illegal: writing `if (ptr && ...)` will cause the compiler to complain loudly. When this first got in, one of my projects broke, and I was rather annoyed at the time. However, when I got around to fixing it, I found that I had to write `if (ptr !is null && ...)` instead, which greatly clarifies the intent and readability of the code.  Since then, I have come to appreciate this change.
> 
> Except that never happened.  Maybe you're thinking of comparing objects to null with ==?

Are you sure?

My original failing code was:

	while (!lex.empty &&
		(op = T.matchOp(lex.front, OpType.infix)) &&
		op.precedence >= minprec)
	{
		...
	}

where op is a pointer type.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

Using an array type in boolean contexts is bug-prone.
Please just write « arr.length » of anything you want.
If you want to see a reasons to forbid it - look at original bug report.

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.1397.1428640119.3111.digitalmars-d@puremagic.com...

> Are you sure?

Pretty sure.

> My original failing code was:
>
> while (!lex.empty &&
> (op = T.matchOp(lex.front, OpType.infix)) &&
> op.precedence >= minprec)
> {
> ...
> }
>
> where op is a pointer type.

Maybe an 'assignment cannot be used as a condition' error?  Nothing to do with pointer types as boolean conditions.

eg if (x = call()) -> if ((x = call()) != null)

Do you have a complete example that gives the error you're talking about? 

On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer wrote:
> A confusing and dangerous "feature" of D was to treat the expression if(arr) as meaning if(arr.ptr).
>
> Anyone coming from any number of other languages may think that if(arr) means "if arr has any elements". Typically one cares what is inside an array, not where it lives.
>
> However, while checking to see if an array has elements is very similar to checking for a null pointer (obviously, a null pointer array should have no elements), it's not equivalent. Therefore, when attempting to fix this confusion, we had to disable the if(arr) check altogether. You must now specify what part of the array you care about, if(arr.ptr) or if(arr.length).
>
> As usual with changes of this nature, there are differing opinions, and differing styles. I personally never use null as a special value for an array, but others do. They use if(arr) to actually mean if(arr.ptr). For these cases, the update will cause some amount of busywork changing these checks.
>
> But when updating Phobos to comply with this change, we found several actual incorrect usages. So I think the change is worth it, and not much busywork. YMMV.
>
> What do you think?
>
> references:
>
> https://issues.dlang.org/show_bug.cgi?id=4733
> https://github.com/D-Programming-Language/dmd/pull/2885
> https://github.com/D-Programming-Language/tools/pull/166
>
> -Steve

This change meens I had to rewrite almost 1k lines of code which almost every one has been wrong :D.

I have lot of code rewriten from php directly to D.

PHP:
http://sandbox.onlinephpfunctions.com/code/b75620f9714784bd888b365b963723a1dc773d08

D:
http://dpaste.dzfl.pl/89f762890526

On 2015-04-09 22:59, Steven Schveighoffer wrote:

> As usual with changes of this nature, there are differing opinions, and
> differing styles. I personally never use null as a special value for an
> array, but others do. They use if(arr) to actually mean if(arr.ptr). For
> these cases, the update will cause some amount of busywork changing
> these checks.
>
> But when updating Phobos to comply with this change, we found several
> actual incorrect usages. So I think the change is worth it, and not much
> busywork. YMMV.
>
> What do you think?

I'm wondering how often in practice .ptr is not null but the array is empty.

-- 
/Jacob Carlborg

On Friday, 10 April 2015 at 08:38:00 UTC, Jacob Carlborg wrote:
> On 2015-04-09 22:59, Steven Schveighoffer wrote:
>
>> As usual with changes of this nature, there are differing opinions, and
>> differing styles. I personally never use null as a special value for an
>> array, but others do. They use if(arr) to actually mean if(arr.ptr). For
>> these cases, the update will cause some amount of busywork changing
>> these checks.
>>
>> But when updating Phobos to comply with this change, we found several
>> actual incorrect usages. So I think the change is worth it, and not much
>> busywork. YMMV.
>>
>> What do you think?
>
> I'm wondering how often in practice .ptr is not null but the array is empty.

When you remove elements from arrays: you end up with slices of length 0 that have a non-null .ptr. Not that rare.