digitalmars.D - do D support something like C# 4.0 co/contra-variance?
- dennis (1/1) Sep 02 2010 http://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravarian...
- bearophile (4/5) Sep 02 2010 I think D2 doesn't support those things yes. But they are useful and may...
- Michal Minich (44/52) Sep 02 2010 I did not explored this area much, but it seems thanks to duck typed D
- Michal Minich (4/12) Sep 02 2010 I just found...
- Olivier Pisano (5/10) Sep 02 2010 I was sure D did support covariance for the return types of overriden
- Nick Sabalausky (8/19) Sep 02 2010 The OP was talking about this:
- Bruno Medeiros (33/38) Oct 15 2010 I haven't read the whole C# article, but I think the way its done in
- Sean Reque (1/1) Oct 15 2010 Java doesn't have variant generic type parameters. Wildcard types in Jav...
- Bruno Medeiros (14/15) Oct 20 2010 What do you mean they are not the same? Yes, they don't work the same
- Bienlein (4/7) Mar 11 2019 Yes, and it is seen as a nuisance in the Java world. Newer JVM
- sighoya (28/29) Mar 10 2019 I think the following could be used as a workaround in most of
http://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravariance
Sep 02 2010
dennis:http://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravarianceI think D2 doesn't support those things yes. But they are useful and may be added to D3. Bye, bearophile
Sep 02 2010
On Thu, 02 Sep 2010 07:38:24 -0400, bearophile wrote:dennis:contravariancehttp://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-I think D2 doesn't support those things yes. But they are useful and may be added to D3. Bye, bearophileI did not explored this area much, but it seems thanks to duck typed D templates, in some cases template covariance and contravariance is achievable implicitly (see the code example). The variance of D templates may be quite hard to specify and implement, given the genericity and complexity of templates. But I'm sure at least some effects are implementable right now - like safe contra/variant cast; and it should be also possible to add variable to types as variance annotations, which are checkable at ct...I might look closer at this some time.. [1] http://www.digitalmars.com/d/2.0/function.html import std.stdio; class Rect { void draw () { writeln ("Rect"); } } class RoundedRect : Rect { override void draw () { writeln ("RoundedRect"); } } class UltraRect : RoundedRect { override void draw () { writeln ("UltraRect"); } } class List (T) { private T[] items; void add (T item) { items ~= item; } T[] getAll () { return items.dup; } } void fill (T) (List!(T) list) { // list.add (new Rect); // errors here: // function List!(RoundedRect).List.add (RoundedRect item) is not callable using argument types (Rect) // cannot implicitly convert expression (new Rect) of type Rect to RoundedRect list.add (new RoundedRect); list.add (new UltraRect); } void drawAll (T) (List!(T) items) { foreach (item; items.getAll()) item.draw(); } void main () { auto l = new List!(RoundedRect); fill (l); drawAll (l); }
Sep 02 2010
On Thu, 02 Sep 2010 07:38:24 -0400, bearophile wrote:dennis:contravariancehttp://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-I think D2 doesn't support those things yes. But they are useful and may be added to D3. Bye, bearophileI just found... http://digitalmars.com/d/2.0/phobos/std_traits.html#isCovariantWith
Sep 02 2010
Le 02/09/2010 13:38, bearophile a écrit :dennis:I was sure D did support covariance for the return types of overriden methods. Cheers, Olivierhttp://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravarianceI think D2 doesn't support those things yes. But they are useful and may be added to D3. Bye, bearophile
Sep 02 2010
"Olivier Pisano" <olivier.pisano laposte.net> wrote in message news:i5oq50$1i0r$1 digitalmars.com...Le 02/09/2010 13:38, bearophile a écrit :The OP was talking about this: class TemplClass(T) {} class Base {} class Derived : Base {} And then having some way to have TemplClass!Derived considered to be derived from TemplClass!Base, or the other way around.dennis:I was sure D did support covariance for the return types of overriden methods.http://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravarianceI think D2 doesn't support those things yes. But they are useful and may be added to D3. Bye, bearophile
Sep 02 2010
On 02/09/2010 12:38, bearophile wrote:dennis:simple. In Java you can have variance with classes as well, not just with interfaces. But more importantly, in Java the generic parameter can automatically be "covariant" or "contravariant" (as per the same sense that the article uses). So for example in Java if you create a class such as ArrayList<T> then it is already implicitly convertible to ArrayList<? extends T> and ArrayList<? super T> ArrayList<out T> and ArrayList<in T> respectively. With ArrayList<? extends T> you can get elements from the list (typed as T), but you can't put elements. And with ArrayList<? super T> you can put elements in the list (typed as T), and you can also get elements, but typed as Object. But the key thing is that you don't have to define these extra interfaces. Imagine for example a dictionary/map class: Map<KEY, VALUE> Whereas in Java you automatically get variance in all possible 4 interfaces... clearly not ideal. Plus, in Java methods can be also be parameterized with generics, which has several interesting and useful usages... In any case this matters little for D. It would be mildly nice to have, yes, but it would be incredibly complicated to so in a language as complex as D. There is already a lot of chunkiness and design issues with the new type modifiers (const, shared, pure, etc.), and adding yet more type stuff, especially with something as complex as covariance/contravariance would be inane with a major redesign of D's typesystem. It might something not so much for D3, as for D4... :-X -- Bruno Medeiros - Software Engineerhttp://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravarianceI think D2 doesn't support those things yes. But they are useful and may be added to D3. Bye, bearophile
Oct 15 2010
Java doesn't have variant generic type parameters. Wildcard types in Java are wildcard types because it doesn't implement generics with erasure. See http://stackoverflow.com/questions/527766/what-is-the-equivalent-of-java-wildcards-in-c-generics.
Oct 15 2010
On 15/10/2010 13:49, Sean Reque wrote:Java doesn't have variant generic type parameters. Wildcard types in Java are wildcard types because it doesn't implement generics with erasure. See http://stackoverflow.com/questions/527766/what-is-the-equivalent-of-java-wildcards-in-c-generics.What do you mean they are not the same? Yes, they don't work the same way, their semantics is fairly different, but they are both attempting to address the same problem: To improve safety/expressiveness in the type system, with regards to variance in generic type parameters. the other way around? ( You're not off to a good start when the article least not clearly. ;) ) generic are not erasures (ie, the generic parameters information is preserver at runtime). -- Bruno Medeiros - Software Engineer
Oct 20 2010
On Friday, 15 October 2010 at 12:49:33 UTC, Sean Reque wrote:Java doesn't have variant generic type parameters. Wildcard types in Java are NOT the same thing and are certainly not more powerful.Yes, and it is seen as a nuisance in the Java world. Newer JVM languages such as Kotlin and Scala do not suffer from this problem.
Mar 11 2019
On Thursday, 2 September 2010 at 10:13:21 UTC, dennis wrote:http://blog.t-l-k.com/dot-net/2009/c-sharp-4-covariance-and-contravarianceI think the following could be used as a workaround in most of the cases. It is not directly covariance, though. void covarianceLike(T)(SList!T list) if(is(ImplicitConversionTargets!T==AliasSeq!(Base,Object))) { return; } SList!SubClass list= SList!Subclass covarianceLike(list); But it is still tedious to write out all base classes as AliasSeq, maybe there is a better workaround (Adding extends and super kws?). With a "super" keyword, we could also simulate many contravariance scenarios. I think, true covariance and contravariance is only of limited use, the abstraction of them doesn't really map to the underlying implementation and may never will so. Even if we would have no problems with them, how would the loan of a list [1,2] to a method accepting SList!Algebraic(Int,String,Object) look like if the list inside changes to [1,2,Object(),3,String(),4]. Should it affect our original list [1,2] at all? Or should all integers be projected out of this heterogenoues list resulting to list [1,2,3,4] in the caller? Modelling covariance and contravariance with parametricity seems a better and safer fit to me.
Mar 10 2019