Bug 321674 (MONO78961) - [generics] runtime should support Covariant / Contravariant generic parameters
Summary: [generics] runtime should support Covariant / Contravariant generic parameters
Status: RESOLVED FIXED
: 359594 (view as bug list)
Alias: MONO78961
Product: Mono: Runtime
Classification: Mono
Component: generics (show other bugs)
Version: unspecified
Hardware: Other All
: P3 - Medium : Major
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-27 21:48 UTC by Kamil Skalski
Modified: 2010-01-07 22:49 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
test.zip (3.06 KB, application/octet-stream)
2006-07-27 21:50 UTC, Thomas Wiest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 20:04:46 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)
Comment 1 Forgotten User vxPDddArjq 2008-02-07 16:44:05 UTC
*** Bug 359594 has been marked as a duplicate of this bug. ***
Comment 2 Marek Safar 2009-05-26 18:03:49 UTC
Could we up the priority of this somehow?
Comment 3 Rodrigo Kumpera 2009-05-26 18:12:24 UTC
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.
Comment 4 Marek Safar 2009-05-27 12:23:11 UTC
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.
Comment 5 Rodrigo Kumpera 2010-01-07 22:49:54 UTC
Fixed in trunk r149199.