Question regarding implicit conversions in the C# language specification

Question

Section 6.1 Implicit conversions defines an identity conversion thusly:

An identity conversion converts from any type to the sam

Answer 1

Update on 22-Sep-2010:

I doubt anybody is going to read this besides Timwi. Even so, I wanted to make a few edits to this answer in light of the fact that a new answer has now been accepted and the debate still continues (at least in my perhaps imaginary world) on whether or not the quoted excerpts of the spec are technically redundant. I am not adding much, but it's too substantial to fit in a comment. The bulk of the update can be found under the heading "Conversion involving the dynamic type" below.

---

Update on 19-Sep-2010:

In your comment:

[T]his doesn’t make sense.

Damn, Timwi, you say that a lot. But all right, then; you've put me on the defensive, so here goes!

Disclaimer: I have definitely not examined the spec as closely as you have. Based on some of your recent questions it seems like you've been looking into it quite a bit lately. This is naturally going to make you more familiar with a lot of details than most users on SO; so this, like most answers you're likely to receive from anyone other than Eric Lippert, may not satisfy you.

Different premises

Firstly, the premise of your question is that if the statements highlighted are redundant, then they serve no purpose. My answer's premise is that redundant statements are not necessarily without purpose if they clarify something that isn't obvious to everyone. These are contradictory premises. And if we can't agree on premises, we can't have a straightforward logical argument. I was simply asking you to rethink your premise.

Your response, however, was to reiterate your premise: "If the sentences are truly redundant, then they only confuse the reader and don't clarify anything."

(I like how you set yourself up as the representative for all readers of the spec there, by the way.)

I can't blame you for holding this position, exactly. I mean, it does seem obvious. And I didn't give any concrete examples in my original answer. So below I will try to include some concrete examples. But first, let me take a step back and offer my take on why this weird identity conversion concept exists in the spec in the first place.

The purpose of the identity conversion definition

Upon first glance, this definition seems rather superfluous; isn't it just saying that an instance of any type T is convertible to ... well, to T? Yes, it is. But I hypothesize* that the purpose of this definition is to provide the spec with the proper vocabulary to utilize the concept of type identity in the context of discussing conversions.

This allows for statements about conversions which are essentially transitive in nature. The first point you quoted from the spec as an example of a tautological statement falls into this category. It says that if an implicit conversion is defined for some type (I'll call it K) to another type T₀ and T₀ has an identity conversion to T, then K is implicitly convertible to T. By the definition of identity conversion given above, "has an identity conversion to" really means "is the same type as." So the statement is redundant.

But again: the identity conversion definition exists in the first place to equip the spec with a formal language for describing conversions without having to say things like "if T₀ and T are really the same type."

OK, time for concrete examples.

Where the existence of an implicit conversion might not be obvious to some developers

Note: A much better example has been provided by Eric Lippert in his answer to the question. I leave these first two examples as only minor reinforcements of my point. I have also added a third example that concretizes the identity conversion that exists between object and dynamic as pointed out in Eric's answer.

Transitive reference conversion

Let's say you have two types, M and N, and you've got an implicit conversion defined like this:

public static implicit operator M(N n);

Then you can write code like this:

N n = new N();
M m = n;

Now let's say you've got a file with this using statement up top:

using K = M;

And then you have, later in the file:

N n = new N();
K k = n;

OK, before I proceed, I realize that this is obvious to you and me. But my answer is, and has been from the beginning, that it might not be obvious to everyone, and therefore specifying it--while redundant--still has a purpose.

That purpose is: to make clear to anyone scratching his or her head, looking at that code, it is legal. An implicit conversion exists from N to M, and an identity conversion exists from M to K (i.e., M and K are the same type); so an implicit conversion exists from N to K. It isn't just logical (though it may be logical); it's right there in the spec. Otherwise one might mistakenly believe that something like the following would be necessary:

K k = (M)n;

Clearly, it isn't.

Transitive boxing conversion

Or take the type int. An int can be boxed as an IComparable, right? So this is legal:

int i = 10;
IComparable x = i;

Now consider this:

int i = 10;
IComparable x = i;

Again, yes, it may be obvious to you, me, and 90% of all developers who might ever come across it. But for that slim minority who don't see it right away: a boxing conversion exists from int to IComparable, and an identity conversion exists from IComparable to IComparable (i.e., IComparable and IComparable are the same type); so a boxing conversion exists from int to IComparable.

Conversion involving the dynamic type

I'm going to borrow from my reference conversion example above and just tweak it slightly to illustrate the identity relation between object and dynamic in version 4.0 of the spec.

Let's say we have the types M and N, and have defined somewhere the following implicit conversion:

public static implicit operator M