Talk:Covariance and contravariance (computer science)

message: I think it would be clearer if this article referred to parameter types (as in, "contravariant method parameter type") instead of argument types. It's not a huge issue since the examples show the intended meaning, but the term itself is potentially confusing because "contravariant argument type" could also refer to something like this:
obj.foo(new Base());
as opposed to:
obj.foo(new Derived());
Covariance and contravariance do not necessarily have the same meaning regarding arguments as they do with parameters. You could have a subclass method (call it bar()) whose parameter was contravariant in comparison with its base class method, but pass it an argument that was covariant as compared to some other call to bar(). So basically, the meaning depends on whether we're talking about the relationship between the methods themselves, or the calls to those methods. Using the term "parameter" instead of "argument" would avoid that ambiguity.
Crunch483 (talk) 09:04, 12 June 2016 (UTC)
replies: text: I feel like the words "argument" and "parameter" are synonyms, so changing from one to another will not disambiguate anything. Vilhelm.s (talk) 00:20, 13 May 2016 (UTC)

text: Technically an argument is what you pass to a function and a parameter is what the function expects/receives. So they're close to being synonymous but do have different meanings. Many if not most programmers are familiar with this distinction. Crunch483 (talk) 09:04, 12 June 2016 (UTC)
thread_title:  "Argument types" vs. "Parameter types" 

message: In the function types section it states:
S1 → S2 ≤ T1 → T2  if T1 ≤ S1 and S2 ≤ T2.
I think this should be
T1 → T2  ≤ S1 → S2 if T1 ≤ S1 and S2 ≤ T2.
Reasoning: if  T1 ≤ S1 then T1 is less general than S1 so clearly T1 → T2 can not be used in all places when S1 → S2 can. Hence T1 → T2 is less general than S1 → S2 and hence it should state T1 → T2  ≤ S1 → S2.
174.21.61.28 (talk) 01:07, 14 June 2015 (UTC)
replies: text: It's not a typo, the correct rule switches the ordering for the function domain but not the function range. This is definitely the trickiest fact about subtyping, if functions were not contravariant like this, there probably wouldn't be a Wikipedia article in the first place. Note that S ≤ T means "S is _more_ general than T" (maybe this is part of what confused you?).  Vilhelm.s (talk) 13:53, 14 June 2015 (UTC)
thread_title:  Incorrect ordering in Function Types section? 

message: I am a java programmer with 8 years of experience. When I end up sitting pretty much baffled by what I read here, there is something fundamentally flawed with the article. Many of these computer science articles are way to tied into the theoretical underpinnings, which is very sad for people actually trying to use Wikipedia as a tool to learn and/or understand things, and to do a "quick look-up" of some aspect. Such theory is obviously important for a complete discussion of the aspect, but should OBVIOUSLY come as a distinct chapter later. The intro should be in a "layman terms" language, importantly exemplified with an example written in some NORMAL generic pseudo-language (not any lisp-like silliness - what stupid idea is that?!), as in "This exemplifies the aspect under discussion". I must say that it is obvious that the hardcode theory geeks are WAY too much in control for the comp.sci. articles, making them read like scientific articles seemingly written for journals - and as I've understand the theory of WP, this is not its intention. Stolsvik (talk) 14:43, 18 December 2008 (UTC)
replies: text: Done. I have changed the introduction to be more along the lines you suggest Vilhelm.s (talk) 21:18, 6 October 2013 (UTC)
thread_title:  Way too complex article!! 

message: This should mention the fact that generic programming supports covariant arguments. For example, adding an element to an STL BackInsertionSequence of type X means adding an X::value_type whereas std::vector<int> (which is a BackInsertionSequence) means adding an int. While int is std::vector<int>::value_type, it is not a subtype of X::value_type. —Ben FrantzDale 18:27, 15 June 2007 (UTC)
replies: text: Done. This was already fixed by someone; now the page explains clearly why that's not covariance. --Blaisorblade (talk) 02:24, 15 July 2008 (UTC)
thread_title:  Contravariance and Generic Programming 

message: The following sentence is very cumbersome. Could someone who understands the issues improve it?
"How types are built from basic types, thus defining the sub-type relationship, and how new methods are defined and override or not existing methods depends on the language and sometimes not necessarily follow the substitution principle above adding runtime checking instead."
Dougher (talk) 03:00, 28 November 2007 (UTC)
thread_title:  Sentence needs editing 

message: The first sentence says
:A covariant type operator in a type system preserves the ordering ≤ of types.  
Fine, but what is this ordering?  This article does not explain it, and neither does type system
The very model of a minor general (talk) 21:53, 1 April 2008 (UTC)
replies: text: Added a link and explained this more clearly in the intro.--Blaisorblade (talk) 02:27, 15 July 2008 (UTC)
thread_title:  Ordering 

message: The first sentence says that a type operator may be covariant or contravariant.  The rest of the article speaks about covariant or contravariant types.    What does it mean for a type to be covariant? 
Also:  I am sure we have an article explaining what a "type operator" is; please link to it. 
--The very model of a minor general (talk) 19:50, 4 April 2008 (UTC)
replies: text: I agree. I made a stab at cleaning it up. —Ben FrantzDale (talk) 03:20, 6 April 2008 (UTC)

text: Covariance/Contravariance are not properties of a type or a method (function, procedure) alone. Rather, they are relations between a method and its argument and result types. Whenever a contravariant type is mentioned, it must be clear from the context what method it is being related to and what position (argument v. result) in the method it is taking.  —Preceding unsigned comment added by 118.68.180.142 (talk) 21:07, 6 June 2008 (UTC)
replies: text:  I can't agree more! Yet in this article, whenever the word covariant or contravariant is used, the context is not clear. It would make sense to say that the type returned by a function is covariant to acceptor's type. The returned type alone is neither covariant, nor contravariant, these adjectives aren't applicable to only one object out of context / not compared to another object.  — Preceding unsigned comment added by 84.108.228.145 (talk) 12:35, 18 October 2011 (UTC)
thread_title:  What is covariant? 

message: The sentence 
"it was shown by Castagna (1995) that all depends on the method fetching algorithm: types used to select the method are contravariant; types not used to select the method are covariant. It is immaterial if the fetching occurs at run-time or at compile time." 
is completely wrong. Castagna (1995) has proved exactly the opposite: "given a method m selected by a messages with parameters, when m is overridden, the parameters that determine the (dynamic) [method] selection must be covariantly overridden (i.e., the corresponding parameters in the overriding method must have a lesser type). Those parameters that are not taken into account in the selection must be contravariantly overridden (i.e., the corresponding in the overriding method must have a greater type.)"  —Preceding unsigned comment added by 118.68.180.142 (talk) 08:16, 7 June 2008 (UTC)
replies: text: Ok, I believe you read the work (I haven't myself), and I understand that Castagna and the article have different contexts. What the article says is more ambiguous, and is correct about overloading, not about overriding. I'll try to read the article and fix out the issue, but the statement you take from the article seems pretty obvious for single-dispatch. --Blaisorblade (talk) 02:33, 15 July 2008 (UTC)
replies: text:  Yes, I confirm what you say, and the sentence in the article was completely wrong. I fixed it, and left mention of the original content, explaining it is about overloading (Castagna's article talks about overloading too, but I use overloading in the C++/Java meaning, i.e. static overload, not multiple dispatch). --Blaisorblade (talk) 03:07, 15 July 2008 (UTC)
thread_title:  Fact on Castagna's work 

message: Excellent -- the article is at just about the level I was looking for.  In particular I was looking for the link to category theory.
However the discussion in 'Origin of the terms' seemed a little confused, with a mention of 'arrows' where I think 'morphisms' was intended, and a rather worrying 'supposedly'.  I have been bold and edited this to fit my understanding (unfortunately I wasn't logged in when I did so), but it would be good if someone with a fully secure understanding of the relationship to category theory could check that I haven't said anything incorrect. NormanGray (talk) 13:52, 17 August 2011 (UTC)
thread_title:  Links to category theory 

message: Note, types may share values yet not be equivalent. For example, types assuming values {a,b} and {b,c}, respectively, are not equivalent to each other...though they are equivalent to a type assuming the values {b} since {b}->{a,b} and {b}->{b,c}.
What a mess, equivalence implies transitivity; so you cannot tell that "A and B are not equivalent, though they are equivalent to C".
You should really define what you mean with "equivalent", and use an other word IMO.
Sedrikov (talk)  —Preceding undated comment added 14:10, 15 September 2011 (UTC)
thread_title:  Some not clear sentence 

message: In my opinion, the phrase "Assuming no side effects are permitted" shouldn't be included. What I assume JC Chu is trying to say here is "Assuming the type system is sound", but this is an assumption you always implicitly make. Languages that allow side-effects that are not explicitly encoded into the type system of course tend to have an unsound type system... —Ruud 12:29, 5 July 2012 (UTC)
replies: text: I think JC Chu may be confusing some kind of behavioral subtyping (like in the Liskov substitution principle) for the static subtyping this article is about. Co/contravariance has nothing to do with the actual behavior of the functions beyond the type signature. If the type signature doesn't mention side-effects, then it is type-safe to substitute a function if it respects the co/contravariant function subtyping rule, whether there are side effects or not. That doesn't mean the substitution will be semantics/behavior preserving: there are usually many different functions with the same type signature. Glaucus (talk) 13:15, 5 July 2012 (UTC)
replies: text:  Yes—and the article should probably mention this as well—but this has even less to do with side-effects: even substituting one pure function for another can break behavioural subtyping.—Ruud 13:38, 5 July 2012 (UTC)

text:  What I was trying to say is that with the type theoretic definition of subtype relation on function types given in the article, you cannot replace calls “everywhere” without assuming that no side effects are permitted.  JC Chu 14:14, 5 July 2012 (UTC)
replies: text:  That assumption seems neither necessary if you're talking about type correctness, nor sufficient if you're talking about semantic correctness. Could you give a concrete example where you think allowing side-effects would cause a problem for type correctness? —Ruud 14:23, 5 July 2012 (UTC)
replies: text:  You’re right. :(  Side effect–freedom is not sufficient for behavior equivalence.  I still think that “everywhere” is misleading, though.  JC Chu 14:34, 5 July 2012 (UTC)
replies: text:  I agree. The way it reads right suggests that you can just swap in function calls. It's really less about making function calls and more about passing functions as an argument. If you expect a function of type A -> B, I can pass in a function of type A' -> B' as long as A' :> A and B :> B', because you can always use an "A' -> B'" like an "A->B". Glaucus (talk) 15:36, 5 July 2012 (UTC)
replies: text:  I think it’s better to not mention “f can replace g” at all—just “f ≤ g since it cares less …” should be enough. JC Chu (talk) 01:35, 6 July 2012 (UTC)
thread_title:  "Assuming no [[side effect (computer science)|side effects]] are permitted" 

message: :contravariant: converting from a general type (Shapes) to a more specialized type (Rectangles)
:For example, a type W that may hold one of the values from the set {a,b,c,d} is wider than a type N that may only hold values from the narrower set {a,b}. Hence, a type conversion from W to N, such as in the case of passing a double to a function expecting a float, is a covariant conversion.
In the example, shouldn't converting from double to float be contravariant?
Will Faught (talk) 01:07, 21 January 2013 (UTC)
replies: text: I agree. This seems to be a contradiction. The Liskov substitution principle page seems to agree with the example rather than the definitions. For the LSP, method arguments can only be widened in a subtype. This is given as contravariance. However, here contravariance is described as specializing a type. This is confusing. Sftrabbit (talk) 11:24, 9 February 2013 (UTC)

text: Fixed.  — Preceding unsigned comment added by 18.111.23.137 (talk) 08:49, 7 May 2013 (UTC)
thread_title:  Contradiction at the beginning 

message: I usually prefer English wikipedia, but the German article is much better. There you can actually see what it means with all the diagrams. 
It would be great if someone put the diagrams into this article. (I'd do it myself but I have no experience with wikipedia.)  — Preceding unsigned comment added by 212.254.197.250 (talk) 07:48, 16 June 2014 (UTC)
replies: text: Ok, I have done this. Vilhelm.s (talk) 03:04, 23 June 2014 (UTC)
thread_title:  English article lacks diagrams, German article has very good ones 

message: At declaration site variance annotations section, in talk about interface suddenly this document says about valid S-ly. But I don't quite get it. I think it needs a bit more clarification about S-ly itself.  — Preceding unsigned comment added by Miauk3 (talk • contribs) 23:51, 18 July 2015 (UTC)
replies: text: The idea is that *S* ranges over "covariant" and "contravariant", and (not-S) flips the sign. This is how the CLR specification is written. I guess another way to write it would be using that obnoxious mathematical "foo (bar)" style, something like "a type is valid covariantly (contravariantly) if: ...Ai is valid contravariantly (covariantly), and the ith parameter to G is declared contravariant, ...". I don't know what is best. Vilhelm.s (talk) 17:44, 19 July 2015 (UTC)
thread_title:  What is S-ly? 

message: "...it is easy to calculate which positions are co- and contravariant: a position is covariant if it is on the left side of an even number of arrows."
Wrong. A'→B→B ≤ A→B→B if A≤A', since function types are right-associative by default (so A→B→B = A→(B→B)). Type theory  — Preceding unsigned comment added by 217.71.45.3 (talk) 18:46, 4 November 2015 (UTC)
replies: text: Yeah, you need to look at the syntax tree of the type, not just the textual representation. Maybe say "under the left side" instead of "on the left side"? You could spell it out more pedantically, "a position is covariant if, when considering the type as an abstract syntax tree, a path from the root to the position passes through (the left side of) an even number of arrow type constructors", but it sounds kindof clumsy. I figure the intended meaning is probably clear from the context? Vilhelm.s (talk) 22:50, 4 November 2015 (UTC)
replies: text:  I agree that the alternative formulations you proposed are opaque but it's just wrong as it stands, so we should think of a better way of formulating it. I substituted "an even number of arrows" with "an even number of arrows applying to it"  — Preceding unsigned comment added by 217.71.47.18 (talk) 13:46, 5 November 2015 (UTC)
thread_title:  Mistake (position co(ntra)variance) 

message: This is a great article that explains a tricky subject very well. Thank you everyone who has worked on this.  — Preceding unsigned comment added by 104.156.100.85 (talk) 13:01, 13 February 2016 (UTC)
thread_title:  Just want to say, this is a great article 

message: In general, I think this is a great article. However, it might help to explain why in the C# examples IEnumerable is covariant while Action is contravariant. The current explanation assumes knowledge of C# that mahy readers probably don't have.173.164.34.106 (talk) 15:28, 18 March 2016 (UTC)
thread_title:  C# examples 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Covariance and contravariance (computer science). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added  tag to http://www.cs.umass.edu/~jaltidor/variance_pldi11.pdf
*Added archive https://web.archive.org/web/20140202190630/http://parleys.com/play/514892250364bc17fc56bb15/chapter0/about to http://parleys.com/play/514892250364bc17fc56bb15/chapter0/about
*Added archive https://web.archive.org/web/20060622001350/http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/pdf/variance.ecoop02.pdf to http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/pdf/variance.ecoop02.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:57, 13 August 2017 (UTC)
thread_title:  External links modified 

message: Any relation to the stated subject is incidental. The true subject is basically "How to program in C#" rather than Covariance. RDXelectric (talk) 08:51, 14 January 2019 (UTC)
thread_title:  This article is awful. 

message: The article suggests PHP constructors are covariant. This is not the case. PHP allows the overriding of constructors with different parameters (documentation 1), (documentaton 2).
Csirmazbendeguz (talk) 23:20, 30 January 2019 (UTC)
thread_title:  Inaccurate PHP example 

message: "This only happens in a pathological case. For example, type 'a t = int: any type can be put in for 'a and the result is still int"
What language is this? 'a looks like the lifetime declaration syntax in Rust, but that's obviously not it. Logically it seems like it's a definition of a generic type alias in some language I don't know. - Linneris (talk) 07:11, 7 October 2021 (UTC)
replies: text: The 'a syntax for type variables is used by languages in the ML family, for example Standard ML and Ocaml. This really should be cleared up in the article. – Tea2min (talk) 10:20, 7 October 2021 (UTC)
thread_title:  First footnote is unclear 

message: Per MOS:LEADSENTENCE,  So it'd be nice to have a quick definition there, then go into more detail in the rest of the lead section. I'm new to this field, so I'm nowhere near confident enough to change it myself, but I'm thinking something like,
Actually, now that I write that out, it feels like the page should be renamed Variance  (computer science). Would that make sense? That seems to fit MOS:PRECISION:  Variance seems to be the topic, while "covariance and contravariance" seems to be overly precise, since those concepts are instances of variance (right?). Then the lead could start something like,
We might also want to link "complex types" to Data_type#Composite_types. I'm just not sure if it's exactly the same concept.
— W.andrea (talk) 21:24, 13 April 2022 (UTC)
thread_title:  Defining the topic