2) Disallow OrderedDictionary to have null keys

The goal of consistency with the BCL just about settles it. But a database analogy adds further support: key columns cannot normally contain nulls.

I'd have to say my preference is no. Although null is a valid value for a reference type, it doesn't naturally follow that null is a valid value for a key. Thinking back on my own development work, I've never needed a null key for either a hash table-type diictionary or a tree-based dictionary. Null values, yes, certainly; null keys no.

<br>

I tend to disagree with the previous comments, even though databases tend not to allow null values as keys, I have used a lot of workarounds to implement simple things like drawing histograms where empty values are indicated as one of the valid values. It’s quite annoying to be forced to have a separate data structures for storing of empty values.

<br>

<br>It’s quite common in the products I’ve been building to have a data column represented by something like:

<br>map&lt; ValueType, vector&lt;int&gt; &gt; ColumnValueOccurances;

<br>vector&lt; int &gt; EmptyRows;

<br>

<br>Where ValueType is typically int, double, string or some date related type and the map contains list of each row where each value occurs, and since I cannot get a decent hash code for null I use a separate vector for empty values.

<br>

Peter,

<br>

<br>I understand why all the comments up until now have been NO NO NO NO!... NO!

<br>

<br>I say, maybe.

<br>The fact is that a null key could be extremely useful in situations when null is a valid value that has to be decoded into another value. Non-null values are also permitted and translate to their decoded values.

<br>The fact is that setting null keys is 99% of the time an exception-worthy deed.

<br>

<br>I'm trying really hard to find a middle ground here, but I can't seem to find one. Creating another set of classes for the sole reason of adding null as the key is absurd.

<br>

<br>I've thought about working this out using Nullable Types, but I'm not familiar with those enough to suggest a way. Could you wrap null in a non-null Nullable&lt;object&gt;?

<br>

<br>I hope my comment might spark something in your mind. :)

Peter: I've commonly run into situations with my own code where null is used as a key in a dictionary.

<br>

<br>Recall that by your definition as long as someone provides a compator delegate, then they can use your class.  I can easily provide a compartor that deals with nulls just fine.

<br>

<br>Null is a perfectly valid value for an instance of a reference type, and so it seems arbitrarily limiting ot exclude it.  If there's one thing i hate its limitations that exist for no good purpose whatsoever.  

no

In VS2005, It should already work ou t of the box using Nullable&lt;T&gt; as Eric mention in C#2.0

<br><a target="_new" href="http://blogs.msdn.com/ericgu/archive/2004/05/27/143221.aspx">http://blogs.msdn.com/ericgu/archive/2004/05/27/143221.aspx</a>

<br>

<br>Does the following not work for you?

<br>

<br>If you need to allow null as a key use the following

<br>Dictionary&lt;int?, string&gt;

<br>which equalivent to

<br>Dictionary&lt;Nullable&lt;int&gt;, string&gt;

<br>

<br>Then you can do the following,

<br>int? nullkey = null;  // nullkey is a Nullable&lt;int&gt; not null

<br>dictionary[nullkey]; // access null key value in the dictionary

<br>

<br>If you don't need to allow null, use the following

<br>Dictonary&lt;int, string&gt;

<br>

<br>P.S.  I haven't personally tried above, but from Eric's post and C#2.0, it should works out of the box.  

<br>

<br>I think you will run into problem when try to &quot;Order&quot; it -- that is, it is clear on the euqality between null and 1.  But not clear is null greater or less than 1.

<br>

<br>

<br>

Ming: that will not work when the type of the variable isn't know ahead of time.

<br>

<br>For example, if I have:

<br>

<br>Foo&lt;T,V&gt;()

<br>{

<br>//should I do:

<br>    IDictionary&lt;T,V&gt; d1;

<br>

<br>//or

<br>    IDictionary&lt;T?,V&gt; d2;

<br>}

<br>

<br>The nullable case only works if you know before hand that the type you are dealing with is a struct.  If you don't know that, then you can't use it.

Since there can be only a null mapping in a container

<br>Why don't you simply use a Default Property, which everycontainer seems to like:

<br>

<br>class Container&lt;K,V&gt; {

<br>  public V DefaultValue {get;set};

<br>  public V this[K key] [

<br>    get { if(key == default(K)) return DefaultValue; }

<br>    set {

<br>      if(key == default(K)) throw new ArgumentNullException(&quot;use DefaultValue&quot;);

<br>      //

<br>   }

<br>  }

Well, after thinking about it some more, it seems to me that option 1 -- allowing null keys in OrderedDictionary but &quot;faking&quot; the implementation of IDictionary -- just isn't tenable. In particular, it's crucial that CopyTo create Count entries in the target array, and there isn't a good way to do that if we can't create KeyValuePairs (or DictionaryEntries) will null keys.

<br>

<br>So -- for now -- I think that OrderedDictionary must disallow null keys.

<br>

<br>However, although your feedback indicates that this isn't particular onerous for most people, I would like to see this restriction lifted for maximum generality. So, I am also going to ask Microsoft to lift this restriction. This suggestion is FDBK12206 on the MSDN feedback site (<a target="_new" href="http://lab.msdn.microsoft.com/productfeedback/">http://lab.msdn.microsoft.com/productfeedback/</a>). Vote for it if you feel strongly. I don't have high hopes, but you never know.

Hello Cyrus,

<br>

<br>I do not recognise you. Are you supporting this null keys idea ?

<br>Why ?

<br>

<br>I clearly dislike it. null value smeels bad.

<br>Can somebody document me real-world needs for this ?

<br>

<br>I preffer to use MyUserType.NoValue static object to represent something that I realy need.

<br>Allowing null values is a clear path to errors.

<br>

<br>Instead of additing support for null Keys I prefer to remove support for null values.

<br>

<br>P.S&gt; Support for null-keys will requere all calls like &quot;key.GetHashCode()&quot; or &quot;key.Equals(anotherKeys)&quot; to be wrapped inside null-checking. Additional code bloat for no reason.

<br>

<br>

AT: I don't like arbitrary restrictions.  I've never written a single collection that has been unable to support null in it :-)

<br>

<br>IMO a collection is broken if it is _ever_ calling key.GetHashCode or key.Equals.  No collection should ever do that.  If it does then that means the person who is using the collection cannot override that behavior themselves.  For example, what if I want a hashtable that is based on identity characteristics.  I won't be able to do it if you're calling the objects .equals method.

<br>

<br>Also, if you do not allow null then I can not use these collections to serialize out arbitrary graphs of objects.  Now I must check every thing I place in the collection to make sure it's not null even though null is a perfectly valid value for an object!

<br>

<br>How would you feel if I created a collection for integers and said &quot;sorry, no -1's allowed&quot;. :-)

<br>