One of my biggest issues dealing with a move from Java to .Net is the fact that there isn't a Set interface in .Net. I know there are libraries I could go and download but what is the reason for not having it built in? There are Maps (Dictionary) and Lists but why not a Set?
Edit: I should clarify that not everyone uses .Net 3.5 yet -- so I'm more or less referring to older versions of .Net
There's HashSet<T> these days, but sadly no interface of which I'm aware.
I think it's simply an omission by the BCL writers. .NET 3.5 has a HashSet class; for earlier versions, I recommend wrapping a Dictionary<T, object>, with nulls in the value field, to replicate O(1) add, remove and lookup time.
Perhaps the reasoning is that a set is really just a list with a particular implementation detail that restricts the items in it to being distinct. Since the distinctness of the list is in the implementation rather than the interface, an interface is not needed.
As others have mentioned, the FCL has the HashSet<T>.
Maybe because of educational considerations.
A typical programmer sees a sets as a magical container that just works no matter how many elements are in it.
If there is no explicit set, a programmer is forced to choose from other types and while doing so reflect on the elements count and appropriate data structure to achieve good performance.
Just a wild guess.
As others have noted, there is a HashSet<T>, which is actually just a set.
The reason it has "hash" in front of it (an implementation detail of the set since it uses hashes to eliminate duplicates) is becase Set is a keyword in VB.NET.
In .NET 4.0 HashSet will be retrofitted to even implement new ISet interface.
I also moved from Java to .Net recently (due to professional employment) and I must admit that my initial problems have also been on collections.
In the current .Net version (3.5 and speaking about C#) you should orientate yourself on
ICollectionIList<T>List<T>IDictionary<TKey,TValue>IEnumerable<T>These are the most commonly used (hope I didn't miss one)