Covariance in delegates doesn't work with ValueType's?

[Aryeh Holzer]

Let me start with a quote from the C# Programmers Reference (where I
learned the cool word "covariance "):

"When a delegate method has a return type that is more derived than the
delegate signature, it is said to be covariant. Because the method's
return type is more specific than the delegate signature's return type,
it can be implicitly converted. The method is therefore acceptable for
use as a delegate."

It then goes on to give an archetypal example using Mammals and Dogs,
which is all well and good because both of those are reference types.
However, I'm working on a piece of code where I wanted to use a value
types for the return type from the delegate, and it just won't work.
Here's some sample code (adapted from the C# Programmers Reference
example actually):

public delegate object MyHandlerMethod ();

public static string MyFirstHandler( )
{
return null;
}

public static int MySecondHandler ()
{
return 1;
}

static void Main(string[] args)
{
MyHandlerMethod handler_1 = new MyHandlerMethod (MyFirstHandler );

// Covariance should allows this delegate, but it doesn't
// error CS0407: 'int MyFirstHandler( )' has the wrong return type
MyHandlerMethod handler_2 = new MyHandlerMethod (MySecondHandle r);
}

I was a bit surprised, since supposedly all value types (such as int)
derive from the same base, System.Object. Furthermore, even specifying
ValueType as the return from the delegate (and limiting its use to value
types such as MySecondHandler , of course) doesn't change anything. Is
there anyway to achieve covariance using ValueType's, or am I missing
something real obvious here?

-Aryeh Holzer

[Jon Skeet [C# MVP]]

Aryeh Holzer <ar**********@g mail.com> wrote:

Let me start with a quote from the C# Programmers Reference (where I
learned the cool word "covariance "):
<snip>
I was a bit surprised, since supposedly all value types (such as int)
derive from the same base, System.Object. Furthermore, even specifying
ValueType as the return from the delegate (and limiting its use to value
types such as MySecondHandler , of course) doesn't change anything. Is
there anyway to achieve covariance using ValueType's, or am I missing
something real obvious here?

I suspect the problem is that value types *don't* actually derive from
the same base class. Value types themselves don't derive from anything.
The boxed version of the value type is the one which derives from
ValueType.

Basically, covariance says, "It's okay, I know I can use the return
value appropriately" - but in the case of value types it can't, because
it's expecting a reference to come back, not an actual value. They
could probably wire it up so that it did the boxing, but I suspect they
haven't for the sake of simplicity. I agree it's a pain though.

You might want to raise this as a feature request on the feedback
centre at http://lab.msdn.microsoft.com/

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Aryeh Holzer]

Jon Skeet [C# MVP] wrote:

Aryeh Holzer <ar**********@g mail.com> wrote:

Let me start with a quote from the C# Programmers Reference (where I
learned the cool word "covariance "):

<snip>

I was a bit surprised, since supposedly all value types (such as int)
derive from the same base, System.Object. Furthermore, even specifying
ValueType as the return from the delegate (and limiting its use to value
types such as MySecondHandler , of course) doesn't change anything. Is
there anyway to achieve covariance using ValueType's, or am I missing
something real obvious here?

I suspect the problem is that value types *don't* actually derive from
the same base class. Value types themselves don't derive from anything.
The boxed version of the value type is the one which derives from
ValueType.

Basically, covariance says, "It's okay, I know I can use the return
value appropriately" - but in the case of value types it can't, because
it's expecting a reference to come back, not an actual value. They
could probably wire it up so that it did the boxing, but I suspect they
haven't for the sake of simplicity. I agree it's a pain though.

You might want to raise this as a feature request on the feedback
centre at http://lab.msdn.microsoft.com/

I'm sure you're right, although the documentation is very confusing,
then. The entries on "Structs", for instance, says "All value types in
C# inherently derive from System.ValueTyp e, which inherits from
System.Object. Value types can be converted to reference types by the
compiler in a process known as boxing." - which kind of implies that
the ValueType is not natively a reference, but must be converted into
one by boxing it.

Thanks for the pointer (ow) to the feedback center, I think I'll head
there now.

[Jon Skeet [C# MVP]]

Aryeh Holzer <ar**********@g mail.com> wrote:

Let me start with a quote from the C# Programmers Reference (where I
learned the cool word "covariance "):
<snip>
I was a bit surprised, since supposedly all value types (such as int)
derive from the same base, System.Object. Furthermore, even specifying
ValueType as the return from the delegate (and limiting its use to value
types such as MySecondHandler , of course) doesn't change anything. Is
there anyway to achieve covariance using ValueType's, or am I missing
something real obvious here?

I suspect the problem is that value types *don't* actually derive from
the same base class. Value types themselves don't derive from anything.
The boxed version of the value type is the one which derives from
ValueType.

Basically, covariance says, "It's okay, I know I can use the return
value appropriately" - but in the case of value types it can't, because
it's expecting a reference to come back, not an actual value. They
could probably wire it up so that it did the boxing, but I suspect they
haven't for the sake of simplicity. I agree it's a pain though.

You might want to raise this as a feature request on the feedback
centre at http://lab.msdn.microsoft.com/

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Aryeh Holzer]

Jon Skeet [C# MVP] wrote:

Aryeh Holzer <ar**********@g mail.com> wrote:

Let me start with a quote from the C# Programmers Reference (where I
learned the cool word "covariance "):

<snip>

I was a bit surprised, since supposedly all value types (such as int)
derive from the same base, System.Object. Furthermore, even specifying
ValueType as the return from the delegate (and limiting its use to value
types such as MySecondHandler , of course) doesn't change anything. Is
there anyway to achieve covariance using ValueType's, or am I missing
something real obvious here?

I suspect the problem is that value types *don't* actually derive from
the same base class. Value types themselves don't derive from anything.
The boxed version of the value type is the one which derives from
ValueType.

Basically, covariance says, "It's okay, I know I can use the return
value appropriately" - but in the case of value types it can't, because
it's expecting a reference to come back, not an actual value. They
could probably wire it up so that it did the boxing, but I suspect they
haven't for the sake of simplicity. I agree it's a pain though.

You might want to raise this as a feature request on the feedback
centre at http://lab.msdn.microsoft.com/

I'm sure you're right, although the documentation is very confusing,
then. The entries on "Structs", for instance, says "All value types in
C# inherently derive from System.ValueTyp e, which inherits from
System.Object. Value types can be converted to reference types by the
compiler in a process known as boxing." - which kind of implies that
the ValueType is not natively a reference, but must be converted into
one by boxing it.

Thanks for the pointer (ow) to the feedback center, I think I'll head
there now.

[Jon Skeet [C# MVP]]

Aryeh Holzer <ar**********@g mail.com> wrote:

I'm sure you're right, although the documentation is very confusing,
then. The entries on "Structs", for instance, says "All value types in
C# inherently derive from System.ValueTyp e, which inherits from
System.Object. Value types can be converted to reference types by the
compiler in a process known as boxing." - which kind of implies that
the ValueType is not natively a reference, but must be converted into
one by boxing it.

Thanks for the pointer (ow) to the feedback center, I think I'll head
there now.

Yes, the value type system *is* very confusing, unfortunately. The ECMA
CLI spec is the clearest here:

<quote>
Not all types defined by a class definition are object types (see
clause 8.2.3); in particular, value types are not object types but they
are defined using a class definition. A class definition for a value
type defines both the (unboxed) value type and the associated boxed
type (see clause 8.2.4). The members of the class definition define the
representation of both: 1. When a non-static method (i.e. an instance
or virtual method) is called on the value type its this pointer is a
managed reference to the instance, whereas when the method is called on
the associated boxed type the this pointer is an object reference.
Instance methods on value types receive a this pointer that is a
managed pointer to the unboxed type whereas virtual methods (including
those on interfaces implemented by the value type) receive an instance
of the boxed type.

1. Value types do not support interface contracts, but their associated
boxed types do.

2. A value type does not inherit; rather the base type specified in the
class definition defines the base type of the boxed type.
</quote>

and

<quote>
Value Types, in their unboxed form, do not inherit from any type. Boxed
value types shall inherit directly from System.ValueTyp e unless they
are enumerations, in which case they shall inherit from System.Enum.
Boxed value types shall be sealed.
</quote>
Still not as clear as it might be - and not helped by typeof(int), for
example, claiming to be a value type but also claiming to derive from
ValueType, etc...

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Aryeh Holzer <ar**********@g mail.com> wrote:

I'm sure you're right, although the documentation is very confusing,
then. The entries on "Structs", for instance, says "All value types in
C# inherently derive from System.ValueTyp e, which inherits from
System.Object. Value types can be converted to reference types by the
compiler in a process known as boxing." - which kind of implies that
the ValueType is not natively a reference, but must be converted into
one by boxing it.

Thanks for the pointer (ow) to the feedback center, I think I'll head
there now.

Yes, the value type system *is* very confusing, unfortunately. The ECMA
CLI spec is the clearest here:

<quote>
Not all types defined by a class definition are object types (see
clause 8.2.3); in particular, value types are not object types but they
are defined using a class definition. A class definition for a value
type defines both the (unboxed) value type and the associated boxed
type (see clause 8.2.4). The members of the class definition define the
representation of both: 1. When a non-static method (i.e. an instance
or virtual method) is called on the value type its this pointer is a
managed reference to the instance, whereas when the method is called on
the associated boxed type the this pointer is an object reference.
Instance methods on value types receive a this pointer that is a
managed pointer to the unboxed type whereas virtual methods (including
those on interfaces implemented by the value type) receive an instance
of the boxed type.

1. Value types do not support interface contracts, but their associated
boxed types do.

2. A value type does not inherit; rather the base type specified in the
class definition defines the base type of the boxed type.
</quote>

and

<quote>
Value Types, in their unboxed form, do not inherit from any type. Boxed
value types shall inherit directly from System.ValueTyp e unless they
are enumerations, in which case they shall inherit from System.Enum.
Boxed value types shall be sealed.
</quote>
Still not as clear as it might be - and not helped by typeof(int), for
example, claiming to be a value type but also claiming to derive from
ValueType, etc...

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too