Is this a compiler bug?

[John Rusk]

Hi,

I have some weird compiler behaviour, so I'm hoping that one of the gurus
here will be able to tell me whether or not it really is a compiler bug.

In short, the compiler is saying that it cannot choose between two
overloaded versions of a method when, IMHO, one overload is clearly a
"better" choice than the other. I've looked through all the rules for
overload resolution, and I can't see any justification for the compiler's
error message.

I'll include a stripped down demonstration of the "bug" below. But first, a
"disclaimer ": yes, I have included an implict conversion operator on one of
the classes and yes, the problem does go away if I remove it. However,
regardless of the fact that I've included it, I still believe the compiler is
wrong about the ambiguity.

What do you think?

Here's the code:

public class A
{
public static implicit operator B(A a)
{
return new B(); //actual implementation omitted
}
}

public class B
{
}

public class ShowError
{
public static void Method(A a, B b)
{ }

public static void Method(B b, A a)
{ }

public static void ThisFailsToComp ile()
{
A a = new A();
Method(a, null);
//Compiler says this call is ambiguous, BUT
//Surely Method(A a, B b) is better than Method(B b, A a)
//since the former requires NO implicit conversion of the first
param
}

}

John

[Pohihihi]

John,

Do not matter if you give Method(a, null); or Method(null, a) either way it
is not clear to the compiler if it is Method((B)a, null) or Method(a, null)
should be called. Guidelines for implicit maintions that implicit conversion
should be very clear and should not create confusion. In this case it is
confusing.

Thanks,
Po

"John Rusk" <Jo******@discu ssions.microsof t.com> wrote in message
news:51******** *************** ***********@mic rosoft.com...

Hi,

I have some weird compiler behaviour, so I'm hoping that one of the gurus
here will be able to tell me whether or not it really is a compiler bug.

In short, the compiler is saying that it cannot choose between two
overloaded versions of a method when, IMHO, one overload is clearly a
"better" choice than the other. I've looked through all the rules for
overload resolution, and I can't see any justification for the compiler's
error message.

I'll include a stripped down demonstration of the "bug" below. But first,
a
"disclaimer ": yes, I have included an implict conversion operator on one
of
the classes and yes, the problem does go away if I remove it. However,
regardless of the fact that I've included it, I still believe the compiler
is
wrong about the ambiguity.

What do you think?

Here's the code:

public class A
{
public static implicit operator B(A a)
{
return new B(); //actual implementation omitted
}
}

public class B
{
}

public class ShowError
{
public static void Method(A a, B b)
{ }

public static void Method(B b, A a)
{ }

public static void ThisFailsToComp ile()
{
A a = new A();
Method(a, null);
//Compiler says this call is ambiguous, BUT
//Surely Method(A a, B b) is better than Method(B b, A a)
//since the former requires NO implicit conversion of the first
param
}

}

John

[John Rusk]

Po,

is not clear to the compiler if it is Method((B)a, null) or Method(a, null)
should be called.
IMHO, the C# documentation says that Method(a, null) is the better match
because its first parameter if already of the correct type. That makes it
better than Method((B)a, null), in which the first parameter requires
conversion. Therefore, according to the documentation, the compiler should
automatically choose Method(a, null).
Guidelines for implicit maintions that implicit conversion
should be very clear and should not create confusion. In this case it is
confusing.

For humans, yes! My point is that, according to the documentation, it
should _not_ confuse the compiler.

John

PS: I do have good reasons for writing such "confusing" code; I just don't
have time and space to describe them here. Anyway, the point is that the
_compiler_ should not get confused.

[Jon Skeet [C# MVP]]

John Rusk <Jo******@discu ssions.microsof t.com> wrote:

I have some weird compiler behaviour, so I'm hoping that one of the gurus
here will be able to tell me whether or not it really is a compiler bug.

No, it's not a bug, although it's subtle.

The first argument favours Method(A, B). However, look at the second
argument, with respect to the list of "better" conversions, where T1 is
A, T2 is B, C1 is the conversion from the null type to A, C2 is the
conversion from the null type to B, and S is the null type.

o T1 and T2 are different conversions (no result)
o S is neither T1 nor T2 (no result)
o There *is* an implicit conversion from T1 to T2, and no implicit
conversion from T2 to T1, so C1 is the better conversion.

So, for the second argument, Method(B,A) is preferred - so the compiler
doesn't know what to do.

Hope that helps - let me know if you want me to go through it in more
detail. (It looks like you've spent time poring over the specs already,
so hopefully the above should be pretty straightforward by now!)

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

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote:

<snip>

Hope that helps - let me know if you want me to go through it in more
detail. (It looks like you've spent time poring over the specs already,
so hopefully the above should be pretty straightforward by now!)

Meant to ask before - would you like me to add a comment on this for
the specification committee? I happen to be looking through the C# 2.0
specs at the moment, and have collected some comments for them. This
strikes me as an area which could do with at least a bit more
explanation - would you mind if I used your example code?

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

[John Rusk]

PS For the record, I've just found a way to resolve the ambiguity in the
example I gave. It ain't pretty, but it's working.

It relies on two facts: firstly, the problem case is when the "b" param is
the null literal. Secondly, we cannot resolve the ambiguity but we _can_
break the "tie" by introducing a third method which is an even _better_
match, in the specific case when the b param is null.

First, I added this class to the project:

public class NullObj
{
private NullObj() //private = no way to construct this class
{ }

public static implicit operator B(NullObj n)
{
return null;
}
}

There's no way to construct it, so the only possible "value" for a
variable/param of this type is "null".

Second, I added two more overrides of the problem method. They look like
this:

public static void Method(A a, NullObj n)
{
Method(a, (B)null);
}

public static void Method(NullObj n, A a)
{
Method((B)null, a);
}

These overrides will "win" when code calls Method(a, null) and Method(null,
a).

E.g. given the call
Method(a, null)

and the following signatures:
1. Method(B b, A a)
2. Method(A a, B a)
3. Method(A a, NullObj n)

#3 wins because compared to #1, its first param is a better conversion and
its second param is no worse; and compared to #2, its first param is no worse
and its second param is a better conversion - due to the one-way implicit
conversion from NullObj to B.

As you know, that conversion is never actually used. The solution still
works even if the new implicit conversion is coded like this:

public static implicit operator B(NullObj n)
{
throw new NotImplementedE xception();
}

In summary, it's kind of ugly but kind of cool too ;-)

In case anyone else ever has this problem, likely Google search strings are
the C# compiler error message, namely: CS0121 (or 0121 or 121) The call is
ambiguous between the following methods or properties.

[John Rusk]

> > Hope that helps - let me know if you want me to go through it in more

detail. (It looks like you've spent time poring over the specs already,
so hopefully the above should be pretty straightforward by now!)

Yes, but when I re-read them yesterday I missed the crucial bit :-) Thanks
for pointing it out.
Meant to ask before - would you like me to add a comment on this for
the specification committee? I happen to be looking through the C# 2.0
specs at the moment, and have collected some comments for them. This
strikes me as an area which could do with at least a bit more
explanation - would you mind if I used your example code?

You're welcome to use my example code. Perhaps it would help if the
reasoning behind this rule was explained a bit more, that might make it
easier it remember.

Regards,

John

[Jon Skeet [C# MVP]]

John Rusk <Jo******@discu ssions.microsof t.com> wrote:

Hope that helps - let me know if you want me to go through it in more
detail. (It looks like you've spent time poring over the specs already,
so hopefully the above should be pretty straightforward by now!)
Yes, but when I re-read them yesterday I missed the crucial bit :-) Thanks
for pointing it out.

No problem. I love this kind of question. (Bit sad, I know.)
Meant to ask before - would you like me to add a comment on this for
the specification committee? I happen to be looking through the C# 2.0
specs at the moment, and have collected some comments for them. This
strikes me as an area which could do with at least a bit more
explanation - would you mind if I used your example code?

You're welcome to use my example code. Perhaps it would help if the
reasoning behind this rule was explained a bit more, that might make it
easier it remember.

Exactly. I can't see why it's there, at the moment. No doubt it'll all
make sense with a bit of explanation.

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

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

John Rusk <Jo******@discu ssions.microsof t.com> wrote:

> > Hope that helps - let me know if you want me to go through it in more
> > detail. (It looks like you've spent time poring over the specs
> > already,
> > so hopefully the above should be pretty straightforward by now!)

Yes, but when I re-read them yesterday I missed the crucial bit :-)
Thanks
for pointing it out.

No problem. I love this kind of question. (Bit sad, I know.)

> Meant to ask before - would you like me to add a comment on this for
> the specification committee? I happen to be looking through the C# 2.0
> specs at the moment, and have collected some comments for them. This
> strikes me as an area which could do with at least a bit more
> explanation - would you mind if I used your example code?

You're welcome to use my example code. Perhaps it would help if the
reasoning behind this rule was explained a bit more, that might make it
easier it remember.

Exactly. I can't see why it's there, at the moment. No doubt it'll all
make sense with a bit of explanation.

Perhaps. The oddities that result from discarding overrides before finding
the best match don't seem to make much sense. (http://tinyurl.com/ckd8e, if
it's been too long.)

[Jon Skeet [C# MVP]]

Mike Schilling <ms************ *@hotmail.com> wrote:

Exactly. I can't see why it's there, at the moment. No doubt it'll all
make sense with a bit of explanation.

Perhaps. The oddities that result from discarding overrides before finding
the best match don't seem to make much sense. (http://tinyurl.com/ckd8e, if
it's been too long.)

Don't worry - that was one of the first things I commented on :)

(And it's surprised everyone I've shown it to so far...)

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