interface IInvariant<TInv> {} interface ICovariant<out TCov> { IInvariant<TCov> M(); // The covariant type parameter `TCov' // must be invariantly valid on // `ICovariant<TCov>.M()' } interface IContravariant<in TCon> { void M(IInvariant<TCon> v); // The contravariant type parameter // `TCon' must be invariantly valid // on `IContravariant<TCon>.M()' }
但我无法想象这不会是类型安全的. (snip *)这是不允许这样做的原因,还是有其他违反我不知道的类型安全的情况?
*我的初步想法是无可比拟的,但尽管如此,答案非常彻底,@Theodoros Chatzigiannakis甚至以令人印象深刻的准确度解释了我的初步假设.
除了回想起来,我意识到我错误地认为ICovariant :: M的类型签名仍然是一个Func< IInvariant< Derived>>>当它的ICovariant< Derived>被分配给ICovariant< Base>.然后,将该M分配给Func< IInvariant< Base>>看起来很好从一个ICovariant< Base>,但当然是非法的.为什么不禁止这最后一个,非常非法的演员? (所以我认为)
我觉得这个错误和切向的猜测减损了这个问题,正如Eric Lippert也指出的那样,但为了历史目的,
The most intuitive explanation to me is that,taking
ICovariant
as an example,the covariantTCov
implies that the methodIInvariant<TCov> M()
could be cast to someIInvariant<TSuper> M()
whereTSuper super TCov
,which violates the invariance ofTInv
inIInvariant
. However,this implication doesn’t seem necessary: the invariance ofIInvariant
onTInv
could easily be enforced by disallowing the cast ofM
.
解决方法
Why does the variance of a class type parameter have to match the variance of its methods’ return/argument type parameters?
它不是,所以问题是基于一个假的前提.实际规则在这里:
https://blogs.msdn.microsoft.com/ericlippert/2009/12/03/exact-rules-for-variance-validity/
现在考虑:
interface IInvariant<TInv> {} interface ICovariant<out TCov> { IInvariant<TCov> M(); // Error }
Is this the reason why this is disallowed,or is there some other case which violates type safety which I’m not aware of?
我没有遵循你的解释,所以让我们来说明为什么不允许你参考你的解释.在这里,让我用一些等效的类型替换这些类型. IInvariant< TINV>可以是T中不变的任何类型,我们假设ICage< TCage> ;::
interface ICage<TAnimal> { TAnimal Remove(); void Insert(TAnimal contents); }
也许我们有一个类型Cage< TAnimal>实现ICage< TAnimal> ;. 我们来替换ICovariant< T>同
interface ICageFactory<out T> { ICage<T> MakeCage(); }
我们来实现接口:
class TigerCageFactory : ICageFactory<Tiger> { public ICage<Tiger> MakeCage() { return new Cage<Tiger>(); } }
一切顺利ICageFactory是协变的,所以这是合法的:
ICageFactory<Animal> animalCageFactory = new TigerCageFactory(); ICage<Animal> animalCage = animalCageFactory.MakeCage(); animalCage.Insert(new Fish());
我们只是把一只鱼放进一只老虎笼里.每一步都是完全合法的,我们最终会遇到类型系统违规.我们得出的结论是,使ICageFactory协调一致不能是合法的.
我们来看看你的逆向例子基本上是一样的:
interface ICageFiller<in T> { void Fill(ICage<T> cage); } class AnimalCageFiller : ICageFiller<Animal> { public void Fill(ICage<Animal> cage) { cage.Insert(new Fish()); } }
现在,界面是相反的,所以这是合法的:
ICageFiller<Tiger> tigerCageFiller = new AnimalCageFiller(); tigerCageFiller.Fill(new Cage<Tiger>());
我们再次把鱼放进老虎笼里.我们再次得出结论,首先将类型违反是非法的.
所以现在让我们考虑一下我们如何知道这些是非法的.在第一种情况下,我们有
interface ICageFactory<out T> { ICage<T> MakeCage(); }
相关规则是:
The return types of all non-void interface methods must be valid covariantly.
ICage< T> “有效协变”?
A type is valid covariantly if it is:
1) a pointer type,or a non-generic class… NOPE
2) An array type… NOPE
3) A generic type parameter type … NOPE
4) A constructed class,struct,enum,interface or delegate typeX<T1,… Tk>
YES! … If the ith type parameter was declared as invariant,then Ti must be valid invariantly.
在ICage< TAnimal>,So T in ICage>中,TAnimal是不变的必须是不变的.是吗?不可变的,不变地必然是有效的,而且是相反的,但它只有共同的有效.
因此这是一个错误.
对逆转案件进行分析是作为一项工作.