> <snip> > > If class B is statically known to implement interface A, then the assignment > is known to be correct. This follows since, even if the exact type of b is a > subtype of B, it will inherit the obligation to implement A. The problem > occurs if A and B are apparently unrelated. In the class object case we > could reject the code as certain to fail. However, in the case of > interfaces, if class B is not sealed, then the exact type of b might be some > subtype of B, validly implementing the interface A. Casts to interface types > are thus seldom able to be rejected at compile time and mostly remain as > runtime type checks in the IL. > > </snip>
Personally, I would PREFER those compile-time checks. After all, if you really MEANT for some B-subtype to always implement the A interface, then declare a BA intermediate type that says so. Ambiguity is the devil's volleyball. If the compiler can help us out with such a costless concession, why throw out the entire type-safety of collections. Marc You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
