Bug in C# 2.0 compiler?

[evgeniy81]

From rsdn.ru forum http://rsdn.ru/Forum/Message.aspx?mid=2454202.

When i try to compile something like this with c# 2.0 compiler there
is a compile time error.

class Foo {
public int F(bool a, int b)
{
return 2;
}

public void runTest()
{
int a = 5;
int b = 6;
int c = 7;

int blah = F(a<b, c >> 2);// compilation error
Console.WriteLine("Blah = " + blah);
}
}

It occurs only when i use "less than"operator.
But if conclude "a<b" expression into round brackets "(a<b)" error
will not occur. Is "less then operator reloaded or this is compiller
bug?

 

[evgeniy81]

I understand, that comiller perceives this expression like generic
type, but is it ok or not?

 

[Carl Daniel [VC++ MVP]]

When i try to compile something like this with c# 2.0 compiler there
is a compile time error.

class Foo {
public int F(bool a, int b)
{
return 2;
}

public void runTest()
{
int a = 5;
int b = 6;
int c = 7;

int blah = F(a<b, c >> 2);// compilation error
Console.WriteLine("Blah = " + blah);
}
}

It occurs only when i use "less than"operator.
But if conclude "a<b" expression into round brackets "(a<b)" error
will not occur. Is "less then operator reloaded or this is compiller
bug?

It's an ambiguity in the grammar for C#. Unless there's a specific
disambiguation rule stated in the language spec that says this should be
interpreted as a non-generic, then you just have to use parentheses to
disambiguate the code.

I don't have the C# 2.0 language grammar/spec handy, but my guess is that
it's not technically a compiler bug but rather something that the language
spec leaves unspecified.

-cd

 

[Alun Harford]

When i try to compile something like this with c# 2.0 compiler there
is a compile time error.

class Foo {
public int F(bool a, int b)
{
return 2;
}

public void runTest()
{
int a = 5;
int b = 6;
int c = 7;

int blah = F(a<b, c >> 2);// compilation error
Console.WriteLine("Blah = " + blah);
}
}

It occurs only when i use "less than"operator.
But if conclude "a<b" expression into round brackets "(a<b)" error
will not occur. Is "less then operator reloaded or this is compiller
bug?

a<b,c> is a generic type - the compiler is doing exactly what it's
supposed to do (the specification does cover this, and it's clear that
this should result in a compiler error).

Alun Harford

 

[Jon Skeet [C# MVP]]

It occurs only when i use "less than"operator.
But if conclude "a<b" expression into round brackets "(a<b)" error
will not occur. Is "less then operator reloaded or this is compiller
bug?

Yes, it is a compiler bug, I believe. In fact, the spec (section 9.2.3)
has your example, modulo renames etc:

<quote>
Example: The statement:
F(G<A, B>(7));
will, according to this rule, be interpreted as a call to F with one
argument, which is a call to a generic method G with two type arguments
and one regular argument. The statements
F(G<A, B>7);
F(G<A, B>>7);
will each be interpreted as a call to F with two arguments.

Your code matches the bottom statement, so should be treated as a call
to F.

 

[Mattias Sjögren]

Is "less then operator reloaded or this is compiller bug?

Yes it's a bug. I believe it's fixed in the Orcas compiler.


Mattias

 

[Jon Skeet [C# MVP]]

Carl Daniel [VC++ MVP]

It's an ambiguity in the grammar for C#. Unless there's a specific
disambiguation rule stated in the language spec that says this should be
interpreted as a non-generic, then you just have to use parentheses to
disambiguate the code.

I don't have the C# 2.0 language grammar/spec handy, but my guess is that
it's not technically a compiler bug but rather something that the language
spec leaves unspecified.

Fortunately, the spec *does* specify the behaviour. Unfortunately it
appears the MS compiler doesn't obey the ECMA spec. (It's possible that
the MS version of the spec, pre-ECMA, doesn't have the same rules.)

 

[Jon Skeet [C# MVP]]

a<b,c> is a generic type - the compiler is doing exactly what it's
supposed to do (the specification does cover this, and it's clear that
this should result in a compiler error).

It seems reasonably clear to me that it *shouldn't* result in a
compilation error. From the spec:

<quote>
The statements
F(G<A, B>7);
F(G<A, B>>7);
will each be interpreted as a call to F with two arguments.
</quote>

The "call to F with two arguments" is exactly the desired behaviour, so
the way I read the spec, the OP's code should work. Could you clarify
why you think it should produce a compilation error?

 

[Willy Denoyette [MVP]]

Yes it's a bug. I believe it's fixed in the Orcas compiler.


Mattias

Yes, this one was corrected in the Orcas compiler ( all builds of v 9.0).

Willy.

 

[Alun Harford]

It seems reasonably clear to me that it *shouldn't* result in a
compilation error. From the spec:

<quote>
The statements
F(G<A, B>7);
F(G<A, B>>7);
will each be interpreted as a call to F with two arguments.
</quote>

The "call to F with two arguments" is exactly the desired behaviour, so
the way I read the spec, the OP's code should work. Could you clarify
why you think it should produce a compilation error?

Oops - sorry.
Yes, you're right.

Alun Harford