Question

I’m just asking this, because the same happened to me when trying to iterate over a DataRowCollection:

DataSet s;
...
foreach (var x in s.Tables[0].Rows)
{
    //IntelliSense doesn't work here. It takes 'x' as an object.
}

I saw @Marc Gravell answer in Why is there no Intellisense with 'var' variables in 'foreach' statements in C#?, and now it’s clear to me why this is happening.

I decided to take a look at the code of the DataRowCollection class, and GetEnumerator() is:

return this.list.GetEnumerator();

where list is a DataRowTree type that inherits the abstract class RBTree<K> (by the way, never knew there was an implementation of a Red-Black Tree in .NET before) which implements IEnumerable instead of IEnumerable<K>.

Is too hard to make RBTree<K> implement IEnumerable<K>? That would solve the main problem here.

I suppose it was developed like this in previous versions of .NET, but that doesn’t really make sense anymore, does it?

My question is:

Is .NET old code updated in new releases? (for example, make DataRowCollection implement IEnumerable<DataRow> instead of IEnumerable)

Answer 1

Breaking changes, such as changing the class hierachy, is only implemented if there’s a really good reason. In this case it’s only for convinience.

An example of why it’s a breaking change:
Let’s say a project has these two methods.

public void Foo(object obj){
   Console.WriteLine(obj.ToString();
}

public void Foo<T>(IEnumerable<T> obj){
  throw new Exception();
}

now the change you want will make a program that has been recompiled but not changed throw an exception every time instead of printing to the console. It’s not that it throws that’s the problem but that the behaviour is different.

There’s other ways such a change could break/alter a perfectly good program so the benefits (being able to write var in foreach loops) does not outweigh the cost (designing, implementing,testing,documenting), nor the potential costs of breaking customers work.