Let's say I have a function like:

void myFunc(List<AClass> theList)
   string[] stuff = new string[theList.Count];

and I pass in an empty list.

Will stuff be a null pointer? Or will it be a pointer to some random place in memory that is uninitialized?

+2  A: 

stuff will be a reference to an array with length theList.Count with all entries initialized to default(string), which is null.

His point was that you pass an empty list to it, i.e. theList.Count is 0. This of course means that there won't be any entries initialized to anything.
In which case it will be a reference to an array with length 0 with all 0 entries initialized to null. ;)
+7  A: 

Why should it? It will just point to an array of size 0, which is perfectly valid.

I think the confusion here arises from the ambiguity of representing the absence of data either bye an array of size 0 set to null (or between an empty string and a string reference set to null for that matter). Both are valid ways to indicate such absence and it would arguably make more sense to have only one. Hence, on some databases an empty string equals the NULL value and vices versa and some programming languages (I think, new versions of C# are one of them) allow to specify references to never be null, also eliminating said ambiguity.

"Both indicate the absence of data and there is no right or wrong way to indicate such absence." But conceptually, there usually is a difference between the two. It's like the difference between having an empty cardboard box and not having a box at all. (I hope I never have to work with databases where "" == NULL, as I would get quite confused by that.)
Oracle apparantly does. I also don't 100% agree with that, because of terinary logic (IS NULL vs = NULL).
NULL == "" is an evil Oracle "feature" - no sane system should generally treat them as equal. My opinion...^^
Daniel Brückner
I think it is a matter of your viewpoint. If you come from a relational-algebra / logical point of view, where you insist on the features of terinary logic, of course such conversion is really bad. On the other hand, from a domain conceptual point of view there are two representation for the same concept of an non-exisiting string.
But even from a conceptual point one can make a difference between not having a string and having an empty string. A user might create a document associate with something so a change from null to an empty string occurs. As long as the user does not enter any text the string will remain empty but that is conceptually different from null.
Daniel Brückner
Though there is no information added. What's the difference in conveied information between having no document at all and having an empty document? Of course you can assign some artificial meaning (e.g. that an empty document means the user intends to add content in the future - but thats a contract on a higher, semantic level), but I really think from a purely mathematical point of view, viewing a set of strings as an algebra, the empty string and a NULL string are the same.
In a database, NULL generally means "this value is unknown". So `MIDDLE_NAME IS NULL` indicates the middle name is unknown, while `MIDDLE_NAME = ''` means this person is known to have no middle name. In C#, the semantics of `null` are much wider (not applicable, not yet set, etc.), but empty strings and arrays would indicate—to me anyway—that the value has been determined to be empty. (Sometimes in a database NULL means "not applicable", but that irritates the hard-core RDBMS theorists. Use with caution.)
Jeffrey L Whitledge

If theList is an actual List object, and is merely empty, then theList.Count is going to return 0. Which means that the declaration becomes

string[] stuff = new string[0];

In other words, stuff will just be an array (of strings) with length 0.

No, stuff will be an empty array of strings, not an empty string.
Eric Lippert
I'm pretty sure stuff is an array of strings, not a string!?
@Eric: I know, I got `string` mixed up with `char` and was thinking in C/C++ terms (thinking too fast has always been one of my failures). Corrected my answer before I even saw your comment.
+4  A: 

This is fine code. You will get an Array object with zero items (allocations) in it.

Brian Genisio
+6  A: 

It will create an empty array object. This is still a perfectly valid object - and one which takes up a non-zero amount of space in memory. It will still know its own type, and the count - it just won't have any elements.

Empty arrays are often useful to use as immutable empty collections: you can reuse them ad infinitum; arrays are inherently mutable but only in terms of their elements... and here we have no elements to change! As arrays aren't resizable, an empty array is totally immutable.

Jon Skeet
The key point I was confused about was whether an empty array takes a non-zero amount of space, as you call it.
As the information about its 'emptyness' has to be stored somewhere (i.e. the count) it has to take up some space. Given what I wrote in my answer, you could of course (but this is dangerous) have the internal guidline that instead of initializing arrays of length 0 you set the reference to null. But this may need some additional checks when such arrays are used and not be worth the slim space savings.
+1  A: 

The following is in the C# language specification:

  • The computed values for the dimension lengths are validated as follows. If one or more of the values are less than zero, a System.OverflowException is thrown and no further steps are executed.
  • An array instance with the given dimension lengths is allocated. If there is not enough memory available to allocate the new instance, a System.OutOfMemoryException is thrown and no further steps are executed.

So for a length of zero, memory is allocated.

Peter van der Heijden

As long as you ensure that your List<> that you actually pass in to the method was initialized somewhere, like

List<Stuff> myStuff = new List<Stuff>;

the list will not point to null. It will be a list of zero Stuffs.