contravariance

In the Nomicon's section about subtyping , it says contravariance is available for a function pointer type. However, I can't find any good examples of this. I tried to code a struct with a function pointer, but the contravariance doesn't seem to work. What is a code example of this? Rust's notion of subtyping only applies to lifetimes . Searching for the term "contra" on the page you linked has numerous relevant paragraphs: Actually witnessing contravariance is quite difficult in Rust, though it does in fact exist. NOTE: the only source of contravariance in the language is the arguments to a

Following on from this question , can someone explain the following in Scala: class Slot[+T] (var some: T) { // DOES NOT COMPILE // "COVARIANT parameter in CONTRAVARIANT position" } I understand the distinction between +T and T in the type declaration (it compiles if I use T ). But then how does one actually write a class which is covariant in its type parameter without resorting to creating the thing unparametrized ? How can I ensure that the following can only be created with an instance of T ? class Slot[+T] (var some: Object){ def get() = { some.asInstanceOf[T] } } EDIT - now got this down

I have the following code: static Func<object, string> s_objToString = (x) => x.ToString(); static Func<string, string> s_stringToString = s_objToString; //compiles static Func<int, string> s_intToString = s_objToString; //error The second line compiles but the third line fails to compile with error: Cannot implicitly convert type ' System.Func<object,string> ' to ' System.Func<int,string> ' Why is that? I understand that with genetics although string is derived from object a List<string> does not derive from List<object> , but here object to string works and object to int fails, why? OK let's

I am not sure if this is a Covariance and Contravariance issue but I cannot get this working. Here is the code: public interface IDto { } public class PaginatedDto<TDto> where TDto : IDto { public int PageIndex { get; set; } public int PageSize { get; set; } public int TotalCount { get; set; } public int TotalPageCount { get; set; } public bool HasNextPage { get; set; } public bool HasPreviousPage { get; set; } public IEnumerable<TDto> Dtos { get; set; } } public class PersonDto : IDto { public int Id { get; set; } public string Name { get; set; } public string Surname { get; set; } public int

Here is a piece of my code: public interface IA<in TInput> { void Method(IB<TInput> entities); } public interface IB<in T> { } I can't figure out why I get following compile error: "Parameter must be input-safe. Invalid variance: The type parameter |TInput| must be contravariantly valid on "IB< in T>". Any help will be appreciated. dasblinkenlight The designator of contravariance in C# (i.e. in ) is intuitive only at the immediate level, when you make a method that "takes in" a parameter of generic type. Internally, however, contravariance means an inversion of a relation ( Q&A with an

Sorry I have asked some questions like this one, but I still can't get a clear answer, maybe my bad English and unclear expression puzzled the kind people. When I read the "Type Parameterization" in this article: http://www.artima.com/pins1ed/type-parameterization.html , I see there are some explanation about the type positions: As a somewhat contrived example, consider the following class definition, where the variance of several positions is annotated with ^+ (for positive) or ^- (for negative): abstract class Cat[-T, +U] { def meow[W^-](volume: T^-, listener: Cat[U^+, T^-]^-) : Cat[Cat[U^+,

This question already has an answer here: Covariance and contravariance real world example 8 answers While reading a section of an article about covariance and contravariance at Wikipedia, I ran into the following, bolded sentence: First consider the array type constructor: from the type Animal we can make the type Animal[] ("array of animals"). Should we treat this as Covariant: a Cat[] is a Animal[] Contravariant: a Animal[] is a Cat[] or neither (invariant)? If we wish to avoid type errors, and the array supports both reading and writing elements, then only the third choice is safe. Clearly