On Thu, 04 Jul 2013 08:52:12 -0400, Regan Heath <regan@netmail.co.nz> wrote:

> On Thu, 04 Jul 2013 12:50:54 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> On Thu, 04 Jul 2013 05:25:30 -0400, Regan Heath <regan@netmail.co.nz> wrote:
>>
>>> On Wed, 03 Jul 2013 19:10:40 +0100, bearophile <bearophileHUGS@lycos.com> wrote:
>>>> Telling apart the literal for an empty array from the literal of a empty but not null array is a bad idea that muds the language. And thankfully this currently fails:
>>>>
>>>> void main() {
>>>>      int[] emptyArray = [];
>>>>      assert(emptyArray !is null);
>>>> }
>>>
>>> As this comes up often you're probably aware that there are people (like myself) who find the distinction between a null (non-existant) array and an empty array useful.
>>
>> Nobody questions that.
>> The biggest problem is making if(arr) mean if(arr.ptr) instead of if(arr.length)
>
> Indeed.  IMO if(arr) should mean if(arr.ptr) .. and I thought it did.. or did this change at some point?

No, it should mean if(arr.length).  It means if(arr.ptr) now, and this is incorrect.  I don't care if an empty array points at null or at some other value, I care if it's empty or not.  You can always use if(arr is null) or if(arr.ptr) if you prefer to distinguish null arrays from non-null ones.  As of now, it's impossible to not care.

>
>> What [] returns should not be an allocation. And returning null is a reasonable implementation of that.
>
> Whether there is an allocation or not is secondary.  The primary goal is for [] to represent empty, not null.  We have null, if we want to represent null we pass null.  What we lack is a way to represent empty.

What I'm saying is that [] returning null is reasonable.  Returning some non-null empty array is also reasonable if it's not an allocation.

In the realm of arrays, you are not supposed to care where it's stored, you only care about the elements and the length.

I would not be opposed to a pull request that made [] be non-null, as long as it doesn't allocate.

-Steve

On Thursday, 4 July 2013 at 13:32:25 UTC, Steven Schveighoffer wrote:
>> Indeed.  IMO if(arr) should mean if(arr.ptr) .. and I thought it did.. or did this change at some point?
>
> No, it should mean if(arr.length).

*I* think it should simply mean compilation error. There is, arguably, a "big" difference between null and empty:

null means not yet initialized, whereas empty means initialized, but contains no info. This is an important distinction for things such as lazy initialization, or just plain checking data integrity. It can also mean important distinctions for serialization, such as JSON or xml, to differentiate between an null node, or a node that contains nothing.

A slice is the abstraction of both pointer and container. Wanting to test null pointer or empty are both legitimate operations.

IMO, you should have to state which you want. Making arbitrary choices for the user in the face of ambiguity is evil.

On 7/4/13 3:00 AM, Dicebot wrote:
> I am afraid I don't really follow here. How introducing new array
> literal (and making old one stronger typed) compromises typeof(null)
> features?

If it has a different type, there's unneeded secession. If it has the same type, it's arguably useless as one could always write (T[K]).init in the rare cases that need disambiguation.

Andrei

On 7/4/13 6:32 AM, Steven Schveighoffer wrote:
> I would not be opposed to a pull request that made [] be non-null, as
> long as it doesn't allocate.

What would be the benefits?

Andrei

On Thursday, 4 July 2013 at 13:32:25 UTC, Steven Schveighoffer wrote:
> On Thu, 04 Jul 2013 08:52:12 -0400, Regan Heath wrote:
>> Indeed.  IMO if(arr) should mean if(arr.ptr) .. and I thought it did.. or did this change at some point?
>
> No, it should mean if(arr.length).  It means if(arr.ptr) now, and this is incorrect.  [..]

The meaning of if(x) for all x of nullable types has always been if(x != null) probably in all languages.

On Thu, 04 Jul 2013 15:45:54 +0100, TommiT <tommitissari@hotmail.com> wrote:

> On Thursday, 4 July 2013 at 13:32:25 UTC, Steven Schveighoffer wrote:
>> On Thu, 04 Jul 2013 08:52:12 -0400, Regan Heath wrote:
>>> Indeed.  IMO if(arr) should mean if(arr.ptr) .. and I thought it did.. or did this change at some point?
>>
>> No, it should mean if(arr.length).  It means if(arr.ptr) now, and this is incorrect.  [..]
>
> The meaning of if(x) for all x of nullable types has always been if(x != null) probably in all languages.

In fact, you can generalise further.

The meaning of if(x) is "compare the value of x with 0" (in C, C++, .. ).

The value of x for a pointer is the address to which it points.
The value of x for a class reference is the address of the class to which it refers.

If D's arrays are reference types, then IMO they should exhibit the same behaviour.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 04 Jul 2013 15:35:30 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/4/13 6:32 AM, Steven Schveighoffer wrote:
>> I would not be opposed to a pull request that made [] be non-null, as
>> long as it doesn't allocate.
>
> What would be the benefits?

Being able to naturally specify a non-null empty array (literal) such that...

char[] n = null;
char[] e = [];

assert(n is null)
assert(e !is null);

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 04 Jul 2013 15:11:49 +0100, monarch_dodra <monarchdodra@gmail.com> wrote:

> On Thursday, 4 July 2013 at 13:32:25 UTC, Steven Schveighoffer wrote:
>>> Indeed.  IMO if(arr) should mean if(arr.ptr) .. and I thought it did.. or did this change at some point?
>>
>> No, it should mean if(arr.length).
>
> *I* think it should simply mean compilation error. There is, arguably, a "big" difference between null and empty:
>
> ...
>
> IMO, you should have to state which you want. Making arbitrary choices for the user in the face of ambiguity is evil.

That's another option, but I for one would be annoyed by this.

I would also argue that it's not ambiguous, if(x) has always meant "compare x with 0" (for me / in C style languages), which in this case means comparing the array reference to null, not comparing the array length to 0.

That is.. if array references are really reference types.  I which case they should obey the same rules/behaviour.

Imagine you had a class Array.

Array a = null;
if (a) // should compare the reference a to 0, not a.length to 0, right?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 07/04/2013 04:35 PM, Andrei Alexandrescu wrote:
> On 7/4/13 6:32 AM, Steven Schveighoffer wrote:
>> I would not be opposed to a pull request that made [] be non-null, as
>> long as it doesn't allocate.
>
> What would be the benefits?
>
> Andrei

- Additional sentinel values at basically no cost.

- No accidental flawed relying on empty array is null or empty array !is null.
  (i.e. less nondeterminism.)

- One thing less to discuss (this has come up before.)

On Thursday, 4 July 2013 at 15:27:17 UTC, Timon Gehr wrote:
> On 07/04/2013 04:35 PM, Andrei Alexandrescu wrote:
>> On 7/4/13 6:32 AM, Steven Schveighoffer wrote:
>>> I would not be opposed to a pull request that made [] be non-null, as
>>> long as it doesn't allocate.
>>
>> What would be the benefits?
>>
>> Andrei
>
> - Additional sentinel values at basically no cost.
>
> - No accidental flawed relying on empty array is null or empty array !is null.
>   (i.e. less nondeterminism.)
>
> - One thing less to discuss (this has come up before.)

There are no benefits to making "[]" return null either. Implementation wise, instead of returning a void[] with "ptr == 0x0" and "length == 0", it could just as well return a void[] with "ptr == 0x1" and "length == 0".

You'd get better behavior at no extra cost.