On Thursday, 4 July 2013 at 12:42:51 UTC, Timon Gehr wrote:
On 07/04/2013 01:50 PM, Steven Schveighoffer wrote:
On Thu, 04 Jul 2013 05:25:30 -0400, Regan Heath
<re...@netmail.co.nz>
wrote:
On Wed, 03 Jul 2013 19:10:40 +0100, bearophile
<bearophileh...@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)
if(arr.ptr) is what it means now.
What [] returns should not be an allocation. And returning
null is a
reasonable implementation of that.
-Steve
static __gshared void[1] x;
return x[0..0];
+1. If you really want null, you can just as well use null for
typeless, or "T[].init" for strong typing.
As stated before:
Reasoning by extrapolation:
int[] arr = [1, 2, 3]; // Array of 3 ints
int[] arr = [1, 2]; // Array of 2 ints
int[] arr = [1]; // Array of 1 ints
int[] arr = []; // Array of 0 ints (not null)
As demonstrated this can be done with no allocations either.
