Bugzilla – Bug 321674
[generics] runtime should support Covariant / Contravariant generic parameters
Last modified: 2010-01-07 22:49:54 UTC
---- Reported by nazgul@omega.pl 2006-07-27 14:48:36 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: In .NET IL (but unfortunately not in C#) it is possible to mark generic parameters as covariant (+) or contravariant (-) It makes possible to convert generic classes to other versions with respect to their generic arguments (like IList<string> to IList<object>). According to .NET 2.0 spec it is allowed only for interfaces and delegates. Unfortunately this aspect of .NET specification is not implemented in Mono now. I present an example Steps to reproduce the problem: 1. Run attached out.exe binary (you can obtain it also by compiling attached IL example) Actual Results: aa Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at Test.processObjects (ICovariantEnumerator`1 x) [0x00000] at Test.Main () [0x00000] Expected Results: aa bb How often does this happen? Always Additional Information: The example is created by Nemerle compiler and works fine on MS.NET. The original code is: interface ICovariantEnumerator [+T] { MoveNext () : bool; Current : T { get; } } [Record] class Enumerator [T] : ICovariantEnumerator [T] { enu : System.Collections.Generic.IEnumerator [T]; public MoveNext () : bool { enu.MoveNext (); } public Current : T { get { enu.Current } } } module Test { public processObjects (x : ICovariantEnumerator [object]) : void { _ = x.MoveNext (); System.Console.WriteLine (x.Current); } public processStrings (x : ICovariantEnumerator [string]) : void { _ = x.MoveNext (); System.Console.WriteLine (x.Current); } public Main () : void { def x = System.Collections.Generic.List (); x.Add ("aa"); x.Add ("bb"); def y = Enumerator (x.GetEnumerator ()); Test.processStrings (y); Test.processObjects (y); } } ---- Additional Comments From nazgul@omega.pl 2006-07-27 14:50:19 MST ---- Created an attachment (id=170170) test.zip Imported an attachment (id=170170)
*** Bug 359594 has been marked as a duplicate of this bug. ***
Could we up the priority of this somehow?
May I ask why? Implementing the current ECMA behavior is a terrible idea because it features non deterministic dispatch in case of ambiguous types. Implementing the MS behavior is a disaster on itself as it's not documented and lore say it's non deterministic too. Also there is the issue that right now no major language ships with support for it. FX 4 is on beta and won't be ready for quite some time, so I see no reason to implement now whatever we decide to.
This is FX 2.0 feature as far as I know. There could be some change for 4.0 but throwing some sort of not implemented/supported exception would be much better than just crashing with SIGSEGV.
Fixed in trunk r149199.