tags:

views:

2280

answers:

5

Does the HashSet collection introduced in .NET 3.5 preserve insertion order when iterated using foreach?

The documentation states, that the collection is not sorted, but it doesn't say anything about insertion order. A pre-release BCL blog entry states that it is unordered, but this article states that it is designed to preserve insertion order. My limited testing suggests, that order is preserved, but that could be a coincidence.

+1  A: 

Yes but insertion order is not sequential :) HashSet internally uses an array and decides where to insert by using a hash function and modulo, like all hash tables. HashSet enumerator basically goes over this array where items can be at random places.

So you cannot use it with foreach and expect it to go over the items with your insertion order.

ssg
+4  A: 

I think the article claiming it preserves ordering is just plain wrong. For simple tests the insertion order may well be preserved due to the internal structure, but it's not guaranteed and won't always work that way. I'll try to come up with a counterexample.

EDIT: Here's the counterexample:

using System;
using System.Collections.Generic;

class Test
{
    static void Main()
    {
        var set = new HashSet<int>();

        set.Add(1);
        set.Add(2);
        set.Add(3);
        set.Remove(2);
        set.Add(4);


        foreach (int x in set)
        {
            Console.WriteLine(x);
        }
    }
}

This prints 1, 4, 3 despite 3 having been inserted before 4.

It's possible that if you never remove any items, it will preserve insertion order. I'm not sure, but I wouldn't be entirely surprised. However, I think it would be a very bad idea to rely on that:

  • It's not documented to work that way, and the documentation explicitly states that it's not sorted.
  • I haven't looked at the internal structures or source code (which I don't have, obviously) - I'd have to study them carefully before making any such claim in a firm manner.
  • The implementation could very easily change between versions of the framework. Relying on this would be like relying on the string.GetHashCode implementation not changing - which some people did back in the .NET 1.1 days, and then they got burned when the implementation did change in .NET 2.0...
Jon Skeet
That is my assumption as well. Unfortunately other articles are claiming the same (based on said article). It would be nice to have a definitive yes/no answer from a reliable source.
Brian Rasmussen
Davy8
+4  A: 

This HashSet MSDN page specifically says:

A set is a collection that contains no duplicate elements, and whose elements are in no particular order.

Michael Burr
Thank you! Don't know how I missed that crucial bit.
Brian Rasmussen
HashSet implies it's based on a hash table. Hash table order depends primarily on the hashcodes of items in the set, not on insertion order.
Qwertie
+1  A: 

The documentation states:

A HashSet<(Of <(T>)>) collection is not sorted and cannot contain duplicate elements. If order or element duplication is more important than performance for your application, consider using the List<(Of <(T>)>) class together with the Sort method.

Therefore it doesn't matter whether it actually preserves the order of elements in the current implementation, because it is not documented as doing so, and even if it appears to now this may change at any point in the future (even in a hotfix to the framework).

You should be programming against documented contracts, not implementation details.

Greg Beech
I agree, but I didn't think the quote above would be sufficient to get the message across. I was pretty sure, that the set would be unordered, I was just looking for some clear documentation.
Brian Rasmussen
A: 

No, a hash set won't preserve insertion order, at least not predictably. You could use a LinkedHashSet (Java), or an equivalent. A LinkedHashSet will preserve order.

If you want order, you shouldn't even be using a set in the first place... its not made for ordered elements, except in exceptional cases.

EDIT: sounds like I'm preaching :-/ Sorry.

Sudhir Jonathan
I'm not trying to use HashSet that way, I am trying to prevent colleagues from doing so.
Brian Rasmussen
ah, okay... we had the same problem on our project here. It was necessary, though, because we wanted an ordered list that had to be full of unique items.
Sudhir Jonathan