Why a casting exception is thrown at runtime instead of handled at compile time for variance mis-match

[scionwest]

I'm not sure if this is a bug, or by design, as it's existed for a while (forever?) in C#. If I have a method called GetFoo() that returns an IEnumerable<IFoo>, then the following code will fail despite FooBarimplementing IFoo

IEnumerable<FooBar> fooBar = GetFoo();

This gives the correct compiler error of

Cannot implicitly convert type 'System.Collections.Generic.IEnumerable<Variance.IBar>' to 'System.Collections.Generic.IEnumerable<Variance.FooBar>'. An explicit conversion exists (are you missing a cast?)

However, if I use the GetFoo() method in a foreach loop, where each element is of Type FooBar, there are no compiler errors. Instead, a runtime exception is thrown.

// No compiler error
foreach(FooBar element in GetFoo())
{
    Console.WriteLine(element.DoBar());
}

The compiler can tell that the Type specified on the left side, can not be safely cast to the IBar returned on the right side of the expression. Shouldn't it have a compiler error to state this?

I can see this being a nice feature, if the developer can 100% with certainty know that GetFoo() will return every element as FooBar; that feels unsafe to me in a language that has strong roots in Type safety.

I have an example that reproduces this if anyone wants to clone and run it.

[HaloFour]

Thought it might be a relic from the days prior to generics but the emitted IL is definitely using the generic interfaces and attempting to downcast. Perhaps a concession prior to variance. Either way it seems to be a common law feature now and probably would be considered a breaking change to resolve as suggested.

[scionwest]

Providing a warning that it wasn't safe, like unused variables and other warnings wouldn't be breaking and provide a valuable safety check.

The other option would be for Visual Studio to handle it with the Roslyn API and give a fix suggestion

[HaloFour]

@scionwest I'd agree, but in a couple of other cases where adding a warning has been suggested it was considered a breaking change as it would break builds that treat warnings as errors. The proposal #1580 seeks to address this better.

[gafter]

Making this an error would be a breaking change.