covariance

Invalid variance: The type parameter 'T' must be contravariantly valid on 'UserQuery.IItem<T>.ItemList'. 'T' is covariant [duplicate]

纵饮孤独 提交于 2019-11-27 23:27:59
This question already has an answer here: T must be contravariantly valid 3 answers Why the property get the error while the method can be compiled? public interface IFoo {} public interface IBar<out T> where T : IFoo {} public interface IItem<out T> where T: IFoo { // IEnumerable<IBar<T>> GetList(); // works IEnumerable<IBar<T>> ItemList { get; set; } // Error! } Error: Invalid variance: The type parameter 'T' must be contravariantly valid on 'UserQuery.IItem<T>.ItemList'. 'T' is covariant. You get the compiler error because you have a property getter ( get ) and a setter ( set ). The

How to check covariant and contravariant position of an element in the function?

北战南征 提交于 2019-11-27 23:14:54
This is a code snippet from one of the articles that I read regarding contravariance and covariance in scala. However, I fail to understand the error message thrown by the scala compiler "error: covariant type A occurs in contravariant position in type A of value pet2 class Pets[+A](val pet:A) { def add(pet2: A): String = "done" } My understanding of this code snippet is that Pets is covariant and accepts objects that are subtypes of A. However, the function add takes in a parameter of type A only.Being covariant means that the Pets can take parameters of Type A and its subtypes. Then how is

C# casting an inherited Generic interface

此生再无相见时 提交于 2019-11-27 22:10:25
I'm having some trouble getting my head around casting an interface I've come up with. It's an MVP design for C# Windows Forms. I have an IView class which I implement on my form classes. There's also an IPresenter which I derive into various specific Presenters. Each Presenter will manage the IView differently depending on the role, for example opening the dialog to enter a new set of data with an AddPresenter as opposed to editing existing data with an EditPresenter which would preload data onto the form. Each of these inherit from IPresenter. I want to use the code as such: AddPresenter

Container covariance in C++

时光怂恿深爱的人放手 提交于 2019-11-27 22:02:51
I know that C++ doesn't support covariance for containers elements, as in Java or C#. So the following code probably is undefined behavior: #include <vector> struct A {}; struct B : A {}; std::vector<B*> test; std::vector<A*>* foo = reinterpret_cast<std::vector<A*>*>(&test); Not surprisingly, I received downvotes when suggesting this a solution to another question . But what part of the C++ standard exactly tells me that this will result in undefined behavior? It's guaranteed that both std::vector<A*> and std::vector<B*> store their pointers in a continguous block of memory. It's also

Why classes that implement variant interfaces remain invariant?

天涯浪子 提交于 2019-11-27 21:27:50
C# 4.0 has extended the co and contravariance further for generic types and interfaces. Some interfaces (like IEnumerable<T> ) are covariants, so I can do things like: IEnumerable<object> ie = new List<string>(); but what about this line? I got a compile-time error List<Object> list = new List<String>(); //Cannot implicitly convert type List<string>' to List<object>' I mean, if List<T> implement IEnumerable<T> why List<T> is still invariant? Is out there a good counterexample that explain why this should not be allowed in C#? Firstly, classes are always invariant in C#. You can't declare a

How to check covariant and contravariant position of an element in the function?

回眸只為那壹抹淺笑 提交于 2019-11-27 19:10:52
问题 This is a code snippet from one of the articles that I read regarding contravariance and covariance in scala. However, I fail to understand the error message thrown by the scala compiler "error: covariant type A occurs in contravariant position in type A of value pet2 class Pets[+A](val pet:A) { def add(pet2: A): String = "done" } My understanding of this code snippet is that Pets is covariant and accepts objects that are subtypes of A. However, the function add takes in a parameter of type A

Difference between covariance and upcasting

旧巷老猫 提交于 2019-11-27 17:41:02
What is the difference between covariance and upcasting, or, more specifically, why are they given different names? I've seen the following example referred to as 'upcasting': string s = "hello"; object o = s; //upcast to 'string' to 'object' Whereas, the following I have seen called 'covariance': string[] s = new string[100]; object[] o = s; IEnumerable<string> ies = new List<string>(); IEnumerable<object> ieo = ies; Now, to my untrained eye, covariance seems to be the same as upcasting, except that it refers the casting of collections. (And of a similar statement can be made regarding

Why is Function[-A1,…,+B] not about allowing any supertypes as parameters?

守給你的承諾、 提交于 2019-11-27 17:31:54
I believe one can define covariance (at least, for objects) as 'the ability to use a value of a narrower (sub) type in place of a value of some wider (super) type', and that contravariance is the exact opposite of this. Apparently, Scala functions are instances of Function[-A1,...,+B] for contravariant parameter types A1, etc. and covariant return type, B. While this is handy for subtyping on Functions, shouldn't the above definition mean I can pass any supertypes as parameters? Please advise where I'm mistaken. Covariance and contravariance are qualities of the class not qualities of the

C++ covariance in parameters

孤街浪徒 提交于 2019-11-27 14:40:18
I wanted to know why C++ does not support co-variance in parameters like in example below or if there is a way to achieve it? class base { public: virtual base* func(base * ptr) { return new base(); } }; class derived : public base { public: virtual derived* func(derived * ptr) override { return new derived(); } //not allowed }; The return type is permissible since derived inherits from base , but the function parameter can't work - not all base instances will be a derived also. What's supposed to happen in the cases where func is called on a pointer to base with a parameter that's not a

How to find the minimum covariant type for best fit between two types?

老子叫甜甜 提交于 2019-11-27 14:37:40
There's IsAssignableFrom method returns a boolean value indicates if one type is assignable from another type. How can we not only test if they are assignable from or to each other, but also know the minimum covariant type for best fit? Consider the following example(C# 4.0) Code // method body of Func is irrelevant, use default() instead Func<char[]> x = default(Func<char[]>); Func<int[]> y = default(Func<int[]>); Func<Array> f = default(Func<Array>); Func<IList> g = default(Func<IList>); g=x; g=y; y=x; // won't compile x=y; // won't compile // following two are okay; Array is the type for