Explicit specification of range variable required when hiding inherited IEnumerable<T>

[Anders Borum]

Hello

I'm developing an API with a number of concrete collections that inherit
from an abstract collection hierarchy. Each inheritance level provides an
implementation of IEnumerable<T>, thus allowing the developer to take full
advantage of the LINQ extensions without having to start with a cast
operation to a concrete type that matches the collection.

I was surprised that the C# compiler was unable to resolve the type of the
range variable when writing LINQ queries against a collection that hides an
inherited IEnumerable<T>. Consider the following example (just to be clear -
I'm fully aware that it is possible to write the following using a generic
collection instead, but please follow me);

public class Animal {}
public class Tiger : Animal {}

public abstract class AnimalCollectio n : IEnumerable<Ani mal>
{
public IEnumerator<Ani malGetEnumerato r()
{
throw new NotImplementedE xception();
}

IEnumerator IEnumerable.Get Enumerator()
{
throw new NotImplementedE xception();
}
}

public class TigerCollection : AnimalCollectio n, IEnumerable<Tig er>
{
public new IEnumerator<Tig erGetEnumerator ()
{
throw new NotImplementedE xception();
}
}

public void ProcessAnimals( )
{
AnimalCollectio n animals = new TigerCollection ();
TigerCollection tigers = new TigerCollection ();

// works
var a1 = from a in animals select a;

// fails (requires explicit specification of t as Tiger)
var t1 = from t in tigers select t;

// works when specifying Tiger explicitly
var t1 = from Tiger t in tigers select t;
}

Error 1 Could not find an implementation of the query pattern for source
type 'TigerCollectio n'. 'Select' not found. Consider explicitly specifying
the type of the range variable 't'.

We were just wondering why the C# compiler is unable to resolve the type
Tiger from the TigerCollection (now that it explicit implements
IEnumerable<Tig er>.

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)

[Marc Gravell]

From the compiler's perspective, it has both IEnumerable<Tig erand
IEnumerable<Ani malto pick from, and neither is "better", so it can't
make the decision on its own. Similarly, if you declare:

static void Test(IEnumerabl e<Animalanimals ) {}
static void Test(IEnumerabl e<Tigertigers) {}

and call Test(tigers);

The call is ambiguous between the following methods or properties:
'Program.Test(S ystem.Collectio ns.Generic.IEnu merable<Animal> )' and
'Program.Test(S ystem.Collectio ns.Generic.IEnu merable<Tiger>) '

but add a static void Test(TigerColle ction tigers) { } and it can do
it.

But it tells you how to fix it (and it is easy to do so), which is
usually enough...

Marc

[Marc Gravell]

To clarify - it *would* be able to pick a better candidate if the
difference was between Foo<Tand Bar<Twhere Foo<T: Bar<T>, but
this is very different to SomeType<Foovs SomeType<Barwhe re Foo :
Bar.

Gotta love variance ;-p

Marc

[Anders Borum]

From the compiler's perspective, it has both IEnumerable<Tig erand

IEnumerable<Ani malto pick from, and neither is "better".

Well, I'm explicit asking for the enumerable object of IEnumerable<Tig er>. I
guess this one should be better than defaulting to the IEnumerable<Ani mal>.

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)

[Anders Borum]

To clarify - it *would* be able to pick a better candidate if the

difference was between Foo<Tand Bar<Twhere Foo<T: Bar<T>, but
this is very different to SomeType<Foovs SomeType<Barwhe re Foo :
Bar.

Don't get me started on variance ;-)

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)

[Marc Gravell]

Well, I'm explicit asking for the enumerable object of IEnumerable<Tig er>.

By adding the "Tiger"? yes.

Interestingly (maybe) this is a rare example of where knowing *less*
about a variable is better:

TigerCollection tigersOrig = new TigerCollection ();
IEnumerable<Tig ertigers = tigersOrig;
....
var t1 = from t in tigers select t;

Now the compiler doesn't have choices - it only knows about
IEnumerable<Tig er>, so it works.

Marc