arrays: if(null == [ ])
Steven Schveighoffer
schveiguy at yahoo.com
Mon May 14 07:37:31 PDT 2012
On Mon, 14 May 2012 06:08:17 -0400, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> wrote:
> Hi! I have a small question:
> Is the test for a null array equivalent to a test for zero-length array?
== tests for length and content equivalence.
'is' tests for both pointer and length equivalence (and therefore, content
equality is implied).
There is a large confusion with null arrays. A null array is simply an
empty array that happens to be pointing to null. Other than that, it is
equivalent to an empty array, and should be treated as such.
One can use the idea that "null arrays are special", but it leads to
likely confusing semantics, where an empty array is different from a null
array. if(arr) should IMO succeed iff length > 0. That is one of the
main reasons of the confusion.
Note that [] is a request to the runtime to build an empty array. The
runtime detects this, and rather than consuming a heap allocation to build
nothing, it simply returns a null-pointed array. This is 100% the right
decision, and I don't think anyone would ever convince me (or Andrei or
Walter) otherwise.
> This is particularly interesting for strings.
> For instance, I could return an empty string from a toString-like
> function
> and the empty string would be printed, but If I returned a null string,
> that would indicate, that there is no string representation and it would
> cause some default string to be printed.
These are the confusing semantics I was referring to ;) I would recommend
we try to avoid this kind of distinction wherever possible.
> So, the question is, if a null array is any different from an empty
> array?
I would say it technically is different, but you should treat it as
equivalent unless you have a really really good reason not to. It's just
another empty array which happens to be pointing at 0.
-Steve
More information about the Digitalmars-d
mailing list