www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fixed-size arrays and 'null'

reply Max Samukha <spambox d-coding.com> writes:
Please consider the following: 

import std.stdio;

void foo(int[3] a) {}

void main()
{
    int[3] a = null; // 1
    a = null; // 2
    foo(null); // 3
    if (a is null){} // 4
    if (a == null){} // 5
}

1 - 2. These compile and issue runtime error. null is implicitly cast
to int[] and the program tries to assign it at runtime. Even if it is
not a bug, the error can be detected at compile-time.

3. Fails, but if 1-2 are ok, I can't see why.

4. Compiles but makes little sense.

5. This may be ok, if 1-2 are ok.

I think all of the above should fail at compile time. Just disallow
null initialization/assignment/comparison for fixed-size arrays.

The new behavior has broken some of my code relying on a type's
nullability and I would like to know if the semantics are officially
approved (provided 3 and 4 are fixed)?
Nov 12 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Max Samukha:


 import std.stdio;
 
 void foo(int[3] a) {}
 
 void main()
 {
     int[3] a = null; // 1
     a = null; // 2
     foo(null); // 3
     if (a is null){} // 4
     if (a == null){} // 5
 }
 
 1 - 2. These compile and issue runtime error. null is implicitly cast
 to int[] and the program tries to assign it at runtime. Even if it is
 not a bug, the error can be detected at compile-time.


In the Delight language this is disallowed:
int[] foo() { return null; }
You must use something like:
int[] foo() { return []; }
That I think is better/more clear.

Bye,
bearophile
Nov 12 2009
parent reply Max Samukha <spambox d-coding.com> writes:
On Thu, 12 Nov 2009 07:42:57 -0500, bearophile
<bearophileHUGS lycos.com> wrote:


Max Samukha:


 import std.stdio;
 
 void foo(int[3] a) {}
 
 void main()
 {
     int[3] a = null; // 1
     a = null; // 2
     foo(null); // 3
     if (a is null){} // 4
     if (a == null){} // 5
 }
 
 1 - 2. These compile and issue runtime error. null is implicitly cast
 to int[] and the program tries to assign it at runtime. Even if it is
 not a bug, the error can be detected at compile-time.


In the Delight language this is disallowed:
int[] foo() { return null; }
You must use something like:
int[] foo() { return []; }
That I think is better/more clear.

Bye,
bearophile


I'm not sure disallowing 'null' for T[] return values is a good idea.
What's the advantage?

Anyway, it's a different matter. Mingling *fixed-size* arrays with
null does make little sense.
Nov 12 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Max Samukha:


 What's the advantage?


null is for a pointer/reference. A dynamic array in D is a struct. [] looks
much better to denote an empty array-struct.

Bye,
bearophile
Nov 12 2009
parent Max Samukha <spambox d-coding.com> writes:
On Thu, 12 Nov 2009 13:53:13 -0500, bearophile
<bearophileHUGS lycos.com> wrote:


Max Samukha:


 What's the advantage?


null is for a pointer/reference. A dynamic array in D is a struct. 


Yes, but dynamic arrays in D are reference types (almost) and array
references (doesn't matter whether they are bare pointers or fat
references) can be tested for nullness and set to null. Like it or
not, there is a distinction between a null array and an empty array,
so I would prefer to use 'null' wherever I want to say 'null array
reference', meaning the struct's ptr member is definitely null.


 [] looks much better to denote an empty array-struct.

Bye,
bearophile
Nov 12 2009
prev sibling parent Max Samukha <spambox d-coding.com> writes:
On Thu, 12 Nov 2009 12:18:26 +0200, Max Samukha <spambox d-coding.com>
wrote:


Please consider the following: 

import std.stdio;

void foo(int[3] a) {}

void main()
{
    int[3] a = null; // 1
    a = null; // 2
    foo(null); // 3
    if (a is null){} // 4
    if (a == null){} // 5
}

1 - 2. These compile and issue runtime error. null is implicitly cast
to int[] and the program tries to assign it at runtime. Even if it is
not a bug, the error can be detected at compile-time.

3. Fails, but if 1-2 are ok, I can't see why.

4. Compiles but makes little sense.

5. This may be ok, if 1-2 are ok.

I think all of the above should fail at compile time. Just disallow
null initialization/assignment/comparison for fixed-size arrays.

The new behavior has broken some of my code relying on a type's
nullability and I would like to know if the semantics are officially
approved (provided 3 and 4 are fixed)?


Since nobody else has anything to say about this, I assume it is a
bug.
Nov 13 2009