Upcast of generics in C# 3.0

[=?Utf-8?B?S29ucmFkIFJ1ZG9scGg=?=]

Hello,

I was wondering if C# 3.0 finally supported generic upcasting. Consider the
following code which does work in C# 2:

string[] xs = {"this", "is", "a", "test"};
object[] ys = xs;

Now, analogously, I would expect the following to work as well:

IEnumerable<stringxs = new string[] { "this", "is", "a", "test" };
IEnumerable<objectys = xs;

As of now, this doesn't work because C# is unable to perform the conversion.
Actually, it is obvious why this code doesn't work: it would require the
creation of a new object, an operation which is not generally supported for
generics at the moment.

However, there is actually no technical reason not to allow this in general
(a proposed solution would have the compiler generate implicit conversion
methods, which, unfortunately, is not possible at the moment either because
the current version of C# does not allow to formulate the required
constraint).

So, long story short, my question: Does this work in C# 3.0? And if it
doesn't: Is there a sensible reason for this? I need this kind of code
constantly and the workarounds I have to use are nothing short of annoying.

[Allan Ebdrup]

"Konrad Rudolph" <Konrad Ru*****@discussions.microsoft.comwrote in message
news:27**********************************@microsof t.com...

Hello,

I was wondering if C# 3.0 finally supported generic upcasting. Consider
the
following code which does work in C# 2:

string[] xs = {"this", "is", "a", "test"};
object[] ys = xs;

Now, analogously, I would expect the following to work as well:

IEnumerable<stringxs = new string[] { "this", "is", "a", "test" };
IEnumerable<objectys = xs;

As of now, this doesn't work because C# is unable to perform the
conversion.

<snip>

I need this kind of code
constantly and the workarounds I have to use are nothing short of
annoying.

Could you provide an example where you need this.

Kind Regards,
Allan Ebdrup

[Allan Ebdrup]

"Allan Ebdrup" <eb****@noemail.noemailwrote in message
news:eh**************@TK2MSFTNGP06.phx.gbl...

>
"Konrad Rudolph" <Konrad Ru*****@discussions.microsoft.comwrote in
message news:27**********************************@microsof t.com...

<snip>

>IEnumerable<stringxs = new string[] { "this", "is", "a", "test" };
IEnumerable<objectys = xs;

Why do you need ys to be IEnumerable<object>
If it's because you want to pass it to a method (M) that takes an
IEnumerable<objectparameter like this:

public void M(IEnumerable<objectparameter){...}

You could chang M to generic method like this:

public void M<T>(IEnumerable<Tparameter) {...}

that way you can pass both IEnumerable<stringand IEnumerable<objectto M

IEnumerable<stringxs = ...
IEnumerable<objectys = ...
M(xs); //this is valid
M(ys); //this is valid

The reason you dont have to specify T when calling M is because the type can
be inferred.
This way you can also pecify a method with a parameter of the type
IEnumerable<IMyInterfacelike this

public void M<T>(IEnumerable<Tparameter) where T : IMyInterface {...}

Does this help any?

Kind Regards,
Allan Ebdrup

[=?Utf-8?B?S29ucmFkIFJ1ZG9scGg=?=]

Considering the immense number of requests for covariance in future C#
versions, this additional thread is somewhat redundant.

[Ben Voigt [C++ MVP]]

"Konrad Rudolph" <Konrad Ru*****@discussions.microsoft.comwrote in message
news:27**********************************@microsof t.com...

Hello,

I was wondering if C# 3.0 finally supported generic upcasting. Consider
the
following code which does work in C# 2:

string[] xs = {"this", "is", "a", "test"};
object[] ys = xs;

In fact, this should not be allowed. The only reason .NET has it was to
attract Java programmers who have had that bug for a very long time.

>
Now, analogously, I would expect the following to work as well:

IEnumerable<stringxs = new string[] { "this", "is", "a", "test" };
IEnumerable<objectys = xs;

Since IEnumerable only allows reading, this should be allowed. But it's not
the case for all interfaces. Also, you wouldn't want the compiler to infer
which interfaces are covariant or contravariant, because only the developer
knows whether the interface is likely to remain that way. There ought to be
an attribute to mark interfaces covariant or contravariant, but as far as I
know you can't pass type placeholders to attributes, nor even the actual
type. So without a significant redesign of .NET, you won't get that
behavior.

[=?Utf-8?B?S29ucmFkIFJ1ZG9scGg=?=]

So without a significant redesign of .NET, you won't get that

behavior.

Well, as far as I know the .NET CTS actually *does* allow generic covariance
and contravariance. C# simply doesn't implement it. Perhaps the most obvious
solution would be to introduce Java-style generic wildcards.

[Nicholas Paldino [.NET/C# MVP]]

Konrad,

No, this is not supported in C# 3.0, and there is a good reason for it.

Instead of using the IEnumerable<Tinterface, lets use List<T>
instances. Say for example you had this abstract class:

abstract class Animal {}

And the following concrete implementations:

class Dog : Animal {}
class Cat : Animal {}

If you then created a list of Dogs, like so:

List<Dogd = new List<Dog>();

Assume you allowed the cast, as you suggest, and did this:

List<Animala = d;

Remember, when you cast, you don't actually change the type of what the
variable is referencing. While variable a is of type List<Animalit points
to an instance of List<Dog>.

Now, because you have a List<Animalyou should be able to do this:

a.Add(new Cat());

Because a really points to a List<Dog>, you get a runtime exception.

Now, it could be argued that you want this behavior, but this is the
reason why it's not currently supported, or will be supported in C# 3.0.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Konrad Rudolph" <Konrad Ru*****@discussions.microsoft.comwrote in message
news:27**********************************@microsof t.com...

Hello,

I was wondering if C# 3.0 finally supported generic upcasting. Consider
the
following code which does work in C# 2:

string[] xs = {"this", "is", "a", "test"};
object[] ys = xs;

Now, analogously, I would expect the following to work as well:

IEnumerable<stringxs = new string[] { "this", "is", "a", "test" };
IEnumerable<objectys = xs;

As of now, this doesn't work because C# is unable to perform the
conversion.
Actually, it is obvious why this code doesn't work: it would require the
creation of a new object, an operation which is not generally supported
for
generics at the moment.

However, there is actually no technical reason not to allow this in
general
(a proposed solution would have the compiler generate implicit conversion
methods, which, unfortunately, is not possible at the moment either
because
the current version of C# does not allow to formulate the required
constraint).

So, long story short, my question: Does this work in C# 3.0? And if it
doesn't: Is there a sensible reason for this? I need this kind of code
constantly and the workarounds I have to use are nothing short of
annoying.

[Jon Skeet [C# MVP]]

On Aug 2, 1:53 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

<snip>

There ought to be
an attribute to mark interfaces covariant or contravariant, but as far as I
know you can't pass type placeholders to attributes, nor even the actual
type. So without a significant redesign of .NET, you won't get that
behavior.

I don't think there's an attribute for covariance/contravariance - I
think there's something in the "plain" metadata for the type.

It's unclear to me whether existing framework types could have the
covariance/contravariance which already exists in the CLR applied
retrospectively without breaking things. I suspect it'll never happen,
effectively :(

Jon

[Jon Skeet [C# MVP]]

On Aug 2, 2:12 pm, Konrad Rudolph
<[e-mail]:

So without a significant redesign of .NET, you won't get that
behavior.

Well, as far as I know the .NET CTS actually *does* allow generic covariance
and contravariance.

Only of interfaces, and only where it's safe to do so. It could apply
to IEnumerable<Tbut not to IList<Tor List<T>. Most of the requests
I've seen have been around List<T>, which wouldn't benefit.

C# simply doesn't implement it.

Neither do any framework types.

Perhaps the most obvious
solution would be to introduce Java-style generic wildcards.

I *believe* that only works as it does in Java because of type
erasure.

Jon

[Ben Voigt [C++ MVP]]

"Konrad Rudolph" <Ko***********@discussions.microsoft.comwrote in message
news:6B**********************************@microsof t.com...

>So without a significant redesign of .NET, you won't get that
behavior.

Well, as far as I know the .NET CTS actually *does* allow generic
covariance
and contravariance. C# simply doesn't implement it. Perhaps the most
obvious
solution would be to introduce Java-style generic wildcards.

A google for "Common Type System" and "covariance" returns countless hits,
changing to "generic covariance" returns exactly zero. Can you provide a
reference?

[Jon Skeet [C# MVP]]

On Aug 2, 2:32 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

A google for "Common Type System" and "covariance" returns countless hits,
changing to "generic covariance" returns exactly zero. Can you provide a
reference?

I can!

At least, I'm not sure whether it's part of the CTS itself, but the
CLI spec talks about it.

Here's Rick Byers on it:

http://blogs.msdn.com/rmbyers/archiv...16/375079.aspx

Jon