I've been using generics in a project that I'm using on Whidbey. They are tremendously convenient when you want to use collection classes. That wasn't really very surprising.

What was surprising - mostly because I hadn't spent any time reading the generics spec - was how useful generic methods would be. For my app, I sometimes needed to fetch a list of values from a database. I didn't want to write a separate function for each type,  and with generic methods, I could write the following:

public List<T> GetValues<T>(string selectStatement)
 OleDbCommand select = new OleDbCommand (selectStatement, connection);
 List<T> list = new List<T> ();
 OleDbDataReader reader = select.ExecuteReader ();  while (reader.Read())
  list.Add ((T)reader[0]);
 return list;

I think that's pretty cool. I wrote several functions like that that perform database operations in a generic (ha ha!) way. So I think generics are going to be cooler than I expected.

I should mention one more thing. If the type you use in the generic method is one of the parameters, the compiler can figure out what generic type you're using, and you don't have to specify it. If I wrote:

        public T Process<T>(T param) {...}

I could call it with:

        int i = inst.Process(12);

and the compiler figures out that I want Procees<int>.

Oh, and before you ask me for the spec, you can't have it... yet... It's still churning due to the ECMA process, and we don't want to release it until it's a bit more concrete.