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.

Well every time anyone has:

arr[n..m]

where n == m, for a start. That includes every slice that's been popFront'd to exhaustion.

For me personally "if (arr)" means "if I have a non-null array and there is something inside", so that something like while (arr) { remove_element(arr[0]); } would also work. Same way it works in Python, where:

a = None
if (a) // evaluates to false

a = []
if (a) // evaluates to false

a = [5]
if (a) // evaluates to true

I think it's worth changing this.

if (arr)

translating to

if (arr.length == 0)

Is immediately obvious for anyone coming from at least a Python background. I have implemented my own hashmaps in a similar way. For my maps, the length is stored in the map so it can be retrieved in O(1) time, and cast(bool) results in map.length == 0. (This extends also to empty sets.)

If we need a deprecation path, we can do it. We just warn about if (arr) for a while, so you are told to use if(arr.length == 0) or if (arr.ptr is null) for a while, then we change the behaviour in another release.

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

As others have mentioned, why not make if(arr) be equivalent to if(arr.length)? It seems that's what everyone actually wants when they type it.

On Fri, 10 Apr 2015 09:35:43 +0000
John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> 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
> 
> As others have mentioned, why not make if(arr) be equivalent to if(arr.length)? It seems that's what everyone actually wants when they type it.

Change semantic is not good idea at all

On Friday, 10 April 2015 at 09:35:44 UTC, John Colvin wrote:
> As others have mentioned, why not make if(arr) be equivalent to if(arr.length)? It seems that's what everyone actually wants when they type it.

Maybe after we kept if(arr) an error for some time.
Python got it right, in C# difference between null and empty causes only problems and nothing else. D has a particularly fitting slice design to get it right too.

On Friday, 10 April 2015 at 09:35:44 UTC, John Colvin wrote:
> 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
>
> As others have mentioned, why not make if(arr) be equivalent to if(arr.length)? It seems that's what everyone actually wants when they type it.

This is not a good idea.

People who writed `if(arr)` were misunderstanding the thing. In every other parts of the language `if(x)` only works for pointers and types implicitely convertibles to bool (and other expressions returning such things...).

They were wrong and their error must not be accepted. An array is more or less like a struct and (POD) structs are never null (i exclude the structs with an alias this from the statement).

Then, imagine that the syntactic shortcut is accepted, this would lead to the following confusion:
---
char[] * arr;
if(arr)
---
Here the test is really about the array being null or not.

It's like in the topic from yesterday:

---
void a(uint p, string a = null){}
---

Totally wrong, the guy should write:

---
void a(uint p, string a = ""){}
---

because if you pass a struct as param, the param is never null !

I'm against the shortcut...it doesn't help to understand how it works. It's a useless and confusing shortcut. Warning about the amibuous usage was the right
to do.

On Friday, 10 April 2015 at 09:27:56 UTC, w0rp wrote:
> If we need a deprecation path, we can do it. We just warn about if (arr) for a while, so you are told to use if(arr.length == 0) or if (arr.ptr is null) for a while, then we change the behaviour in another release.

That's kind of the roadmap, though we'd need to wait quite a while until we can reuse it.
I've been thinking about moving std.array.empty to object. Then that could more easily become the replacement idiom.

if (arr) -> if (!arr.empty)

It's much clearer and also what you need to write when you work with ranges.

"Martin Nowak"  wrote in message news:lgjobvhvilvdymfatoje@forum.dlang.org...

> I've been thinking about moving std.array.empty to object. Then that could more easily become the replacement idiom.
>
> if (arr) -> if (!arr.empty)
>
> It's much clearer and also what you need to write when you work with ranges.

if (arr.length) is just as clear, and the same thing.

I use arr.length when I'm working with arrays, and .empty when working with general ranges.  I generally prefer not to mix the two. 

"John Colvin"  wrote in message news:vhujlbdtjodfvrmwckrl@forum.dlang.org...

> As others have mentioned, why not make if(arr) be equivalent to if(arr.length)? It seems that's what everyone actually wants when they type it.

That's the long term idea, but an immediate change would break code.