c# – 为什么类类型参数的方差必须与方法的返回值/参数类型参数的方差相匹配?

前端之家收集整理的这篇文章主要介绍了c# – 为什么类类型参数的方差必须与方法的返回值/参数类型参数的方差相匹配?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
以下提出投诉:
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 covariant TCov implies that the method IInvariant<TCov> M() could be cast to some IInvariant<TSuper> M() where TSuper super TCov,which violates the invariance of TInv in IInvariant. However,this implication doesn’t seem necessary: the invariance of IInvariant on TInv could easily be enforced by disallowing the cast of M.

解决方法

到目前为止,我并不确定您是否已经在任何答案中回答了问题.

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&gt ;::

interface ICage<TAnimal> {
  TAnimal Remove();
  void Insert(TAnimal contents);
}

也许我们有一个类型Cage< TAnimal>实现ICage< TAnimal&gt ;. 我们来替换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 type X<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是不变的必须是不变的.是吗?不可变的,不变地必然是有效的,而且是相反的,但它只有共同的有效.

因此这是一个错误.

对逆转案件进行分析是作为一项工作.

原文链接:https://www.f2er.com/csharp/95339.html

猜你在找的C#相关文章