This is the
talk page for discussing improvements to the
Covariance and contravariance (computer science) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
To-do list for Covariance and contravariance (computer science):
|
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)
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)
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)
I second your opinion. The article would also need some preable like "if you come from python, stop reading here or you'll become blind" :)
81.208.7.130 (
talk) 08:48, 19 May 2009 (UTC)
I believe that the first paragraph should contain a simple, concrete example and relate it to what most OO programmers understand. Perhaps something like:
Many type systems allow instances of a subclass to be treated as if they were instances of their superclass. This is known as the [Liskov substitution principle]. When a type system allows generic types, other situations come up in which you may want to be able to substitute one class for another. For example, if you want to be able to treat a List<Hedgehog> as if it were a List<Animal>, then List would be said to be *covariant*. If you want to be able to treat an Action<Animal> as if it were an Action<Hedgehog>, then Action would be said to be *contravariant*. Kybernetikos ( talk) 16:37, 30 October 2012 (UTC)
This still needs work. Or I know at least the intro needs work, since I didn't dare read any further, when even the intro was nearly incomprehensible. It's ironic that I then grokked the whole concept from Kybernetikos' example above. In the talk section, rather than from the intro to the article itself. 2604:3D08:497F:F430:2D07:2062:45A7:8754 ( talk) 16:24, 20 October 2019 (UTC)
This really needs to be cleaned up with some explanation that is not so heavily tied to object-oriented programming. -- Saforrest 06:17, 18 April 2006 (UTC)
Well, I think we have something clean, explaining the terms in general and applied to OO. The languages part section at the end needs review. Carlos Aya 05:43, 20 September 2006 (UTC)
I agree -- I think is is very important that the OO language application details remain. There should be some discussion on the relationship with generics. Adw2000 14:30, 14 June 2007 (UTC)
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)
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)
I took a stab at improving it, but don't know for sure if it's any better now, since I come from a programming background as well. -- 81.243.7.205 ( talk) 09:38, 9 June 2008 (UTC)
The first example is unclear if not broken:
"The array type is usually covariant on the base type: since String ≤ Object then ArrayOf(String) ≤ ArrayOf(Object)."
The definition talks about type operators being either covariant, contravariant or invariant. Now suddenly the array type is supposed to be covariant?
"if insert and remove operators are permitted, then the insert operator is covariant (e.g. one can insert a String into an ArrayOf(Object)) and the remove operator is contravariant"
Insert and remove are not type operators. So again, how does this relate to the definition?
I think the example should mention that type safety requires
--
83.77.239.59 (
talk) 16:24, 25 December 2007 (UTC)
This falls under the same title, but I mean the very first example - double vs float. The example, in my opinion, poorly represents the relation of types, I'd suggest using types like `real' and `rational' instead, because float isn't a variant of double and double isn't a variant of float. Here is why: most commonly used floats are 32-bits, 64-bits and 128-bits floats, the size and the precision of the float commonly don't depend on the system and the language that uses them. Double is a type used in much fewer languages and really means "two times the size of the int(eger)", where what is integer is left for the language and / or system to define. More yet, numbers like negative zero, infinities and not-a-number aren't representable in double and the number of bits in double may or may not store the information contained in the float - depends what float and what double you are talking about. Commonly, floats are signed, double may or may not be signed. Float may represent numbers larger then those that may be represented in double, but not all doubles can be precisely represented in float - this depends on the number of bits the float uses, the precise format and so on. The example may be intuitive, to an extend, for C++ programmers, but, not even for them, because it really depends on the compiler you use and sets of defines etc... Also, when the article uses the word "narrow" to mean "more specific" it contradicts itself when using the word "narrow" as in type that has fewer properties (which would be exactly the opposite - "less specific"). I'd rather be in favor of eliminating "narrow" places, where it refers to the type signature being visually narrower then those where "narrow" means "specific". — Preceding unsigned comment added by 84.108.228.145 ( talk) 12:53, 18 October 2011 (UTC)
The first sentence says
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)
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)
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)
Some relevance towards covariance/contravariance has changed in C#4.0 [2]. Maybe a note should be made of this...
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)
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).
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)
In the example, shouldn't converting from double to float be contravariant? Will Faught ( talk) 01:07, 21 January 2013 (UTC)
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)
Suppose A≤B. There is a terminological split about what to call a type constructor T such that neither T<A> ≤ T<B> or T<B> ≤ T<A>; is this "invariant" or "non-variant"? Similarly, if both T<A>≤T<B> and T<B>≤T<A>; is this "invariant" or "bivariant"?
If we go through the current list of references in the article,
The other references do not mention these terms. So in this sample, there seems to be an even split between "nonvariant" and "invariant" as a term for "neither", and nobody uses "invariant" to mean "both". I've updated the article to reflect this.
Vilhelm.s ( talk) 16:50, 26 March 2014 (UTC)
A type constructor is said to be covariant in an argument if subtyping in that argument is preserved by the constructor. It is said to be contravariant if subtyping in that argument is reversed by the constructor. It is said to be invariant in an argument if subtyping for the constructed type is not affected by subtyping in that argument.
We have seen a number of examples of covariant type constructors (records and variants, as well as function types, on their right-hand sides) and one contravariant constructor (arrow, on the left-hand side). The List constructor is also covariant [...]
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)
"...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)
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)
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)
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:
{{
dead link}}
tag to
http://www.cs.umass.edu/~jaltidor/variance_pldi11.pdfWhen you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 21:57, 13 August 2017 (UTC)
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)
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)
"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)
'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)Per
MOS:LEADSENTENCE, If possible, the page title should be the subject of the first sentence.
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,
Covariance and contravariance are concepts in programming language type systems that describe how types can be substituted in a given expression: using subtypes or supertypes, respectively. Variance is the general concept.
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: Usually, titles should unambiguously define the topical scope of the article, but should be no more precise than that.
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,
Variance is a concept in programming language type systems that describes how types can be substituted in a given expression. Covariance and contravariance are two such relations, indicating that a type can be substituted with subtypes or supertypes, respectively. On the other hand, invariance means that the type is not substitutable.
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.
This is the
talk page for discussing improvements to the
Covariance and contravariance (computer science) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
To-do list for Covariance and contravariance (computer science):
|
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)
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)
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)
I second your opinion. The article would also need some preable like "if you come from python, stop reading here or you'll become blind" :)
81.208.7.130 (
talk) 08:48, 19 May 2009 (UTC)
I believe that the first paragraph should contain a simple, concrete example and relate it to what most OO programmers understand. Perhaps something like:
Many type systems allow instances of a subclass to be treated as if they were instances of their superclass. This is known as the [Liskov substitution principle]. When a type system allows generic types, other situations come up in which you may want to be able to substitute one class for another. For example, if you want to be able to treat a List<Hedgehog> as if it were a List<Animal>, then List would be said to be *covariant*. If you want to be able to treat an Action<Animal> as if it were an Action<Hedgehog>, then Action would be said to be *contravariant*. Kybernetikos ( talk) 16:37, 30 October 2012 (UTC)
This still needs work. Or I know at least the intro needs work, since I didn't dare read any further, when even the intro was nearly incomprehensible. It's ironic that I then grokked the whole concept from Kybernetikos' example above. In the talk section, rather than from the intro to the article itself. 2604:3D08:497F:F430:2D07:2062:45A7:8754 ( talk) 16:24, 20 October 2019 (UTC)
This really needs to be cleaned up with some explanation that is not so heavily tied to object-oriented programming. -- Saforrest 06:17, 18 April 2006 (UTC)
Well, I think we have something clean, explaining the terms in general and applied to OO. The languages part section at the end needs review. Carlos Aya 05:43, 20 September 2006 (UTC)
I agree -- I think is is very important that the OO language application details remain. There should be some discussion on the relationship with generics. Adw2000 14:30, 14 June 2007 (UTC)
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)
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)
I took a stab at improving it, but don't know for sure if it's any better now, since I come from a programming background as well. -- 81.243.7.205 ( talk) 09:38, 9 June 2008 (UTC)
The first example is unclear if not broken:
"The array type is usually covariant on the base type: since String ≤ Object then ArrayOf(String) ≤ ArrayOf(Object)."
The definition talks about type operators being either covariant, contravariant or invariant. Now suddenly the array type is supposed to be covariant?
"if insert and remove operators are permitted, then the insert operator is covariant (e.g. one can insert a String into an ArrayOf(Object)) and the remove operator is contravariant"
Insert and remove are not type operators. So again, how does this relate to the definition?
I think the example should mention that type safety requires
--
83.77.239.59 (
talk) 16:24, 25 December 2007 (UTC)
This falls under the same title, but I mean the very first example - double vs float. The example, in my opinion, poorly represents the relation of types, I'd suggest using types like `real' and `rational' instead, because float isn't a variant of double and double isn't a variant of float. Here is why: most commonly used floats are 32-bits, 64-bits and 128-bits floats, the size and the precision of the float commonly don't depend on the system and the language that uses them. Double is a type used in much fewer languages and really means "two times the size of the int(eger)", where what is integer is left for the language and / or system to define. More yet, numbers like negative zero, infinities and not-a-number aren't representable in double and the number of bits in double may or may not store the information contained in the float - depends what float and what double you are talking about. Commonly, floats are signed, double may or may not be signed. Float may represent numbers larger then those that may be represented in double, but not all doubles can be precisely represented in float - this depends on the number of bits the float uses, the precise format and so on. The example may be intuitive, to an extend, for C++ programmers, but, not even for them, because it really depends on the compiler you use and sets of defines etc... Also, when the article uses the word "narrow" to mean "more specific" it contradicts itself when using the word "narrow" as in type that has fewer properties (which would be exactly the opposite - "less specific"). I'd rather be in favor of eliminating "narrow" places, where it refers to the type signature being visually narrower then those where "narrow" means "specific". — Preceding unsigned comment added by 84.108.228.145 ( talk) 12:53, 18 October 2011 (UTC)
The first sentence says
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)
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)
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)
Some relevance towards covariance/contravariance has changed in C#4.0 [2]. Maybe a note should be made of this...
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)
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).
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)
In the example, shouldn't converting from double to float be contravariant? Will Faught ( talk) 01:07, 21 January 2013 (UTC)
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)
Suppose A≤B. There is a terminological split about what to call a type constructor T such that neither T<A> ≤ T<B> or T<B> ≤ T<A>; is this "invariant" or "non-variant"? Similarly, if both T<A>≤T<B> and T<B>≤T<A>; is this "invariant" or "bivariant"?
If we go through the current list of references in the article,
The other references do not mention these terms. So in this sample, there seems to be an even split between "nonvariant" and "invariant" as a term for "neither", and nobody uses "invariant" to mean "both". I've updated the article to reflect this.
Vilhelm.s ( talk) 16:50, 26 March 2014 (UTC)
A type constructor is said to be covariant in an argument if subtyping in that argument is preserved by the constructor. It is said to be contravariant if subtyping in that argument is reversed by the constructor. It is said to be invariant in an argument if subtyping for the constructed type is not affected by subtyping in that argument.
We have seen a number of examples of covariant type constructors (records and variants, as well as function types, on their right-hand sides) and one contravariant constructor (arrow, on the left-hand side). The List constructor is also covariant [...]
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)
"...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)
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)
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)
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:
{{
dead link}}
tag to
http://www.cs.umass.edu/~jaltidor/variance_pldi11.pdfWhen you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 21:57, 13 August 2017 (UTC)
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)
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)
"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)
'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)Per
MOS:LEADSENTENCE, If possible, the page title should be the subject of the first sentence.
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,
Covariance and contravariance are concepts in programming language type systems that describe how types can be substituted in a given expression: using subtypes or supertypes, respectively. Variance is the general concept.
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: Usually, titles should unambiguously define the topical scope of the article, but should be no more precise than that.
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,
Variance is a concept in programming language type systems that describes how types can be substituted in a given expression. Covariance and contravariance are two such relations, indicating that a type can be substituted with subtypes or supertypes, respectively. On the other hand, invariance means that the type is not substitutable.
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.