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

[Mike Schilling]

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

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...)

I have a writeup on it, including an example and suggestions for addressing
it. It didn't motivate the Microsoft folks I gave it to, but you're welcome
to it, if you'd like.

[Jon Skeet [C# MVP]]

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

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...)

I have a writeup on it, including an example and suggestions for addressing
it. It didn't motivate the Microsoft folks I gave it to, but you're welcome
to it, if you'd like.

Unfortunately, I can't see a way of fixing it at this point - if
existing apps rely on the current overloading rules, changing the rules
would break those apps.

I'm hoping that it'll at least be recognised as a flaw in future
versions...

--
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...

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

> 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...)

I have a writeup on it, including an example and suggestions for
addressing
it. It didn't motivate the Microsoft folks I gave it to, but you're
welcome
to it, if you'd like.

Unfortunately, I can't see a way of fixing it at this point - if
existing apps rely on the current overloading rules, changing the rules
would break those apps.

It's not possible to make the compiler choose a different overload, but it
is possible to have the problematical cases cause a compilation error.
(That is, fix the overload rules, and consider any situation where new and
old rules would choose different ones "problematical" ) Since the bad
behavior is the compiler choosing the wrong overload, not runtime dispatch
to the wrong override, there is no change to the behavior of binaries.
And it would need to be fixed gradually, over a few versions (silence
becomes warning becomes error, with a flag at each stage to escalate
warnings to errors, or vice versa.)

[John Rusk]

> Exactly. I can't see why it's there, at the moment. No doubt it'll all

make sense with a bit of explanation.

Thinking about it over the past day or so, I've concluded that the rule
(about one-way implicit conversions) is there because its a clever way to
"kill two birds with one stone". Perhaps you've thought of this too, so I'd
be interested in whether you think MS were wrong to take this approach, or
whether this explaination fails to adequately explain their decision.

Here's how it kills two birds with one store. Consider two specific cases:

Case A, subclasses:

void Method(object o)
void Method(MyClass o)

if you call it with something that has a compile-time type of MyClass, it
will call the second version. (Exactly _why_ you'd write code like this, I
don't know, since it depends on the compile-time type not the run-time type,
which is icky. But anyway, it ties in with the next case....)

Case B, numeric types:

void Method(double d)
void Method(int i)

if you call it with an int, it should choose the second one - and it will
because int is convertable to double but not vice versa.

Why is this similar to the first case? Because, in the first case, MyClass
"is a" object. In the second case, in some sense, an int "is a" double.
I.e. the one-way-conversion rule generalizes the usual "is a" semantics of
inheritance, to apply them in a more general sense. If X is implicity
convertable to Y, then in a sense any X "is a" Y.

In all cases, the rule picks the most specific override - i.e. the class at
the bottom of the tree of "is a" relationships. I.e. it picks int instead of
double, and MyClass instead of object.

Anyway, that's the only rationale that I've been able to think of, for the
rule.

As for the other issue mentioned elsewhere in this thread - in which C#
picks the wrong method due to where the various versions where defined in the
class heirarchy - that's _got_ to be a compiler bug, surely!

[Mike Schilling]

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

As for the other issue mentioned elsewhere in this thread - in which C#
picks the wrong method due to where the various versions where defined in
the
class heirarchy - that's _got_ to be a compiler bug, surely!

No, it's strictly according to the spec. See the thread I referenced (via
tinyurl) for the gruesome details.

[John Rusk]

class heirarchy - that's _got_ to be a compiler bug, surely!

No, it's strictly according to the spec. See the thread I referenced (via
tinyurl) for the gruesome details.

Opps, that's what I meant - more a "spec bug" than "code bug", as you and
Jon have discussed in the other thread. I can't believe that MS don't seem
to be listening to your concerns!

[Jon Skeet [C# MVP]]

John Rusk <Jo******@discu ssions.microsof t.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.

Thinking about it over the past day or so, I've concluded that the rule
(about one-way implicit conversions) is there because its a clever way to
"kill two birds with one stone". Perhaps you've thought of this too, so I'd
be interested in whether you think MS were wrong to take this approach, or
whether this explaination fails to adequately explain their decision.

<snip>

Ah, yes. I think you're right - although a better example would be:

void Method(object o)
void Method(MyBaseCl ass o)

and you call it with an expression of type MyDerivedClass (with the
obvious hierarchy). In the example you gave, you'd instantly run into
the rule of "if the type is exactly correct, use that one".

Now, that suggests a good transformation of your code to show what's
going on. Consider this:

public class Derived: Base
{
}

public class Base
{
}

class Example
{
static void Method(Derived a, Base b)
{
}

static void Method(Base b, Derived a)
{
}

static void Main()
{
A a = new A();
Method(a, null);
}
}

It now seems more reasonable for the compiler to complain, because null
as a Derived is more specific than null as a Base.

I'll edit my annotation appropriately.

--
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]

I'll edit my annotation appropriately.

Cool.

Did you also intend to change the first line of Main(), from using A to
using Derived?

John

PS I hope you'll also be able to find a way to encourage some
clarification/documentation of the case where there's no inheritance, just an
implicit conversion. It's probably a rarer case, but that makes it more
confusing when it does crop up.

---
John Rusk
http://www.agilekiwi.com

[Jon Skeet [C# MVP]]

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

I'll edit my annotation appropriately.
Cool.

Did you also intend to change the first line of Main(), from using A to
using Derived?

Yes. Fixed now, thanks :)
PS I hope you'll also be able to find a way to encourage some
clarification/documentation of the case where there's no inheritance, just an
implicit conversion. It's probably a rarer case, but that makes it more
confusing when it does crop up.

Possibly. I'll see what I can do. I'm not saying I have *any* power in
these matters, btw - all I can do is comment.

--
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