UInt64 comparison operators ambiguity

[VBAndCs]

I posted this in https://github.com/dotnet/corefx/issues/35890 but it seems to be language related, so I posted it here too:

Using comparison operators (>, < , etc…) between UInt64 type and any signed type like sbyte , short, int and long causes ambiguity in C#. Try:

  var n1 = 5ul;
  var n2 = 4;
  Console.WriteLine(n1 > n2);

it will cause the error:

Operator '>' is ambiguous on operands of type 'ulong' and 'int'

I understand that arithmetic operations between UInt64 type and any signed type is tricky because we can't predict the resultant type and the user must do the necessary casting according to his needs, but a comparison is a deterministic operation that yields a Boolean value, so there is no way to be ambiguous. The easiest workaround is to cast the ulong to decimal to do the comparison between two decimals, which comes with a high cost and seems unnecessary!
I wrote these functions to compare ulong and signed types. I suggest you use the same approach to define necessary overloads for the CompareTo method and operator overloads in UInt64, SByte, Int16, Int32 and Int64 , so comparisons between ulong and signed types becomes unambiguous.

        private int Compare(ulong n1, sbyte n2)
        {
            if (n2 < 0)
                return 1;

            if (n1 > 127ul )
                return 1;

            return ((sbyte)n1).CompareTo(n2);
        }

        private int Compare(ulong n1, short n2)
        {
            if (n2 < 0)
                return 1;

            if (n1 > 32767ul)
                return 1;

            return ((short)n1).CompareTo(n2);
        }

        private int Compare(ulong n1, int n2)
        {
            if (n2 < 0)
                return 1;

            if (n1 > 2147483647ul)
                return 1;

            return ((int)n1).CompareTo(n2);
        }

        private int Compare(ulong n1, long n2)
        {
            if (n2 < 0)
                return 1;

            if (n1 > 9223372036854775807ul)
                return 1;

            return ((long)n1).CompareTo(n2);
        }

Note:
All positive types other than ulong can be compared normally to any signed types. That is becuase the language uses the comparison operator of int or long. The problem of ulong is that it needs to be casted to decimal and this is not effiecint, so the language markd it as ambiguity, while there is a rather cheap, logiacl and easy slution for this.

[MkazemAkhgary]

you can save one if statement either this way

// if (n2 < 0) return 1; // no need to check. if n1 is smaller than 128 it can be safely cast to sbyte
if (n1 > 127ul ) return 1;
return ((sbyte)n1).CompareTo(n2);

or this way

if (n2 < 0) return 1; 
// if (n1 > 127ul ) return 1; // no need to check. if n2 is bigger than 0 it can be safely cast to ulong
return (n1).CompareTo((ulong)n2);

[VBAndCs]

@MkazemAkhgary
Thanks.
I saw another comment of you where you suggested:
if (a - (ulong)b > 0)
if is clever but will cause an exception if it is inside checked block.

you can save one if statement either this way

I don't know what has a better performance: Checking a value of a type, or casting a value to another type. If the cost of casting is low, then tour code is better, otherwise, we use as many if as needed.

Note: My issue here is not how to fin a workaround. I simply want the compiler to fix this issue so we can use the intrinsic type ulong as expected.

[yaakov-h]

Relevant portion of the spec:

https://github.com/dotnet/csharplang/blob/master/spec/types.md#integral-types

The integral-type unary and binary operators always operate with signed 32-bit precision, unsigned 32-bit precision, signed 64-bit precision, or unsigned 64-bit precision:

For the binary +, -, *, /, %, &, ^, |, ==, !=, >, <, >=, and <= operators, the operands are converted to type T, where T is the first of int, uint, long, and ulong that can fully represent all possible values of both operands. The operation is then performed using the precision of type T, and the type of the result is T (or bool for the relational operators). It is not permitted for one operand to be of type long and the other to be of type ulong with the binary operators.

The spec doesn't allow for a resolution here as there is no way to convert both int and ulong to any of the four mentioned types.

The simplest workaround seems to be a shorter version of the if statements above, i.e. b >= 0 && (ulong)b > a and similar forms with inverted operators for the other binary operators.

At the moment this can be solved with user-defined methods including extension methods. For now, there's nothing that CoreFX or Roslyn can do unless the LDM changes the spec.

[VBAndCs]

@yaakov-h
I think Roslyn itself can use the workarround to fix the issue. There is no overloaded operators in CoreFx for intrinsic types, so it is a matter of Roslyn and it can solve it without cahnging the spec. Or there is something I am missing here?

[yaakov-h]

Roslyn has to follow the spec.

[miloush]

@yaakov-h to be fair the spec explicitly forbids only long and ulong comparisons binary operators. It does not say anything about comparing sbyte, short or int with ulong. Obviously, there is no type T in the list that can "fully represent all possible values of both operands", but I don't see how having such a relational operator would violate the spec.

[VBAndCs]

@yaakov-h @miloush
I tend to consider this as a bug, or at least unfinished busyness. This code shows why:

ulong a = 0;
z = a > long.MaxValue;

C# compiles the above code correctly. It casts long.MaxValue to ulong, because if is obviously safe to do so. but this is not the only safe case, as I showed in my proposal. C# compiler needs only to do a little more checks.

[MkazemAkhgary]

I removed my comment of if (a - (ulong)b > 0) because that was totally wrong. because - operator of two ulong operands returns ulong result and ulong > 0 is always true. @VBAndCs

I think casting is cheaper than if statement. since this operator can be used in many scenarios it should be optimized very well.

[miloush]

@VBAndCs unfortunately I think in that case it is following the spec, as I imagine both operands are of type ulong at the point when it reaches this section about binary operators.

[VBAndCs]

While we are in the subject of numeric casts, there is a problem in casting an object that contains a numeric type to another numeric type:

object o = 1;
var a = (int)o; // OK
var c = (long)o; // runtime error (InvalidCastException)
var d = Convert.ToUInt64(o); //Ok
var d = (long)(int)o; //Ok

o = (byte)1;
var x = (int)o; // runtime error (InvalidCastException)
var y = Convert.ToUInt32(o); //Ok
var z = (int)(byte)o; //Ok

Can't C# compiler do something about that? Why should I write two casts, while the Convert class does it directly?

[miloush]

@VBAndCs I suggest you open another issue on that topic.

[VBAndCs]

@MkazemAkhgary

I think casting is cheaper than if statement. since this operator can be used in many scenarios it should be optimized very well.

I think casting involving creating a new type, and in your example you cast to the bigger-size type, which is relatively slower in comparison.

[VBAndCs]

@miloush

unfortunately I think in that case it is following the spec, as I imagine both operands are of type ulong at the point when it reaches this section about binary operators.

My point is that C# decided to make the cast from long to ulong in this specific case, which means that C# does some checks. any other long value will not be casted including long.MinValue. So, C# can add some more checks to resolve the comparison operation ambiguity.

[MkazemAkhgary]

On a 64-bit machine arithmetic operations are going to be 64-bit anyways. the casting doesn't create a new type, I think this is going to be performed on CPU registers so it would be insanely fast. branches are more expensive because of the cost of branch prediction.

[mikedn]

I simply want the compiler to fix this issue so we can use the intrinsic type ulong as expected.

At the same time, others might expect that types such as ulong do behave like "intrinsics". That is, an operation like n1 < n2 does not generate magic code to cover all possible cases.

There are of course exceptions. For example (u)long operations on 32 bit CPUs generate multiple instructions and even calls to helper methods. Long operations are reasonably useful and it would be impractical to forbid such operations on 32 bit CPUs. Especially on a platform that allows you to write programs that run on different architectures without requiring recompilation.

But you'll have a hard time convincing language designers to support such mixed type comparisons. Especially when usage of unsigned type in C# is very low and when other similar languages (C/C++, Java) do not support this either.

[VBAndCs]

@mikedn

But you'll have a hard time convincing language designers to support such mixed type comparisons. Especially when usage of unsigned type

As I said, this is only related to ulong. We can compare byte to int, sbyte to ushort (both casted to int), short to uint (bith casted to long). The expected behaviour with ulong and signed type is to cast both to decimal to do the comparison. If this is costy, then c# can workarrount to emit the nececaty IL code to do the comparison with the smallest size type as I showwd.
The problem here is that current behaviour led me to write wrong code, when I casted each signed type atomatically to ulong just to get rid of the error! At least add some suggestions to the pulp to help fix ulong arithmetic and binary erros.

[yaakov-h]

A code-fix might be useful here, and definitely has a much lower bar for acceptance. That would need to be discussed over on the Roslyn repo.

[miloush]

So this repo is for when you think changing the specification is the right thing to do. Your option basically would be to propose changing

the operands are converted to type T, where T is the first of int, uint, long, and ulong that can fully represent all possible values of both operands.

into

the operands are converted to type T, where T is the first of int, uint, long, ulong and decimal that can fully represent all possible values of both operands.

That however includes operators you don't care about and I suspect might not go very well. The other option you have is to ask for this case to be explicitly mentioned as allowed in the specification.

---

If you don't care about the specification and want the compiler to support this comparison, this should go to the Roslyn repo as @yaakov-h said. I haven't tried, but I am guessing that changing the appropriate ERR to DEC in this table would be the simplest change that would result in the behaviour you want. However, I imagine emitting the negative check you suggest would be preferred to decimal precision operation from the performance point of view - and could still keep long and ulong comparisons illegal as per spec.

Moreover, the decimal is not as 1st class citizen as the other integral types. For example,

var l = 9223372036854775807; // long
var u = 9223372036854775808; // ulong
var m = 18446744073709551616; // error without suffix

Allowing "implicit decimal comparisons" without bringing the decimal experience on par with other types anywhere else sounds like a hack that would need some justification.

---

At least add some suggestions to the pulp to help fix ulong arithmetic and binary erros.

That also goes to the Roslyn repo. However, note that casting long to ulong and comparing it is a valid and reasonable code, I wouldn't flag it during compilation, that breaks existing code.

The problem here is that current behaviour led me to write wrong code

I think this is the strongest point you have. The compiler error message is misleading and I would support the request to make the problem clearer or suggest alternatives. You could probably create a quick fix that does the work for you too.

---

My point is that C# decided to make the cast from long to ulong in this specific case,

My point was that this is not a runtime cast. The compiler treats it as an ulong constant:

ulong a = 0;
const long m = long.MaxValue;
bool z = a > m;

as you noticed works. It's ulong and ulong comparison. However,

ulong a = 0;
long m = long.MaxValue;
bool z = a > m;

results in the error.

[VBAndCs]

@miloush
Thanks.
I posted this issue in two repos. I wish there is some mechanism to communicate between repos, not to repeat the discussion. Can't we just mention some admin from Rosluyn repo to take the right action based on this issue?

[miloush]

@VBAndCs Don't worry, someone from the team will join soon and give some background on this/suggestions.

[VBAndCs]

@miloush
Another notice:

ulong a = 0;
bool z = a > sbyte.MaxValue;

This code will not compile because C# sees it ambiguous! It has no problem with int.MaxValue and long.MaxValue, but has with sbyte.MaxValue!

[MkazemAkhgary]

@VBAndCs looks like a bug since MaxValue is constant.

[mikedn]

This code will not compile because C# sees it ambiguous!

Seems correct to me. https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#binary-numeric-promotions says:

Otherwise, if either operand is of type ulong, the other operand is converted to type ulong, or a binding-time error occurs if the other operand is of type sbyte, short, int, or long.

It has no problem with int.MaxValue and long.MaxValue, but has with sbyte.MaxValue!

Yes, due to https://github.com/dotnet/csharplang/blob/master/spec/conversions.md#implicit-constant-expression-conversions

A constant_expression (Constant expressions) of type int can be converted to type sbyte, byte, short, ushort, uint, or ulong, provided the value of the constant_expression is within the range of the destination type.

Now I suppose it's kind of strange that a > sbyte.MaxValue does not work and a > 127 does work. But if there was a way to have an sbyte typed literal (e.g. 127sb) then a > 127sb would also fail. And of course, a > (sbyte)127 fails too.

It does indeed seem that the error message could be improved. I don't really know what "ambiguous" means in Operator '<' is ambiguous on operands of type 'ulong' and 'sbyte'. If you have something like:

  static bool GreaterThan(int x, int y) => x > y;
  static bool GreaterThan(long x, long y) => x > y;
  static bool GreaterThan(uint x, uint y) => x > y;
  static bool GreaterThan(ulong x, ulong y) => x > y;
  static bool Test(ulong x) => GreaterThan(x, sbyte.MaxValue);

the error message is Argument 2: cannot convert from 'sbyte' to 'ulong' which seems more reasonable. But then if your next move is to add an explicit cast to ulong just to make the error go away then there's not a lot that the compiler can do. It did try to tell you that you are doing something wrong.

[khm1600]

@mikedn

Now I suppose it's kind of strange that a > sbyte.MaxValue does not work and a > 127 does work.

sbyte.MaxValue is (sbyte)0x7F according to Reference Source and https://github.com/dotnet/corefx and is therefore not allowed to be converted to ulong implicitly because its type is sbyte.

[MkazemAkhgary]

A constant_expression (Constant expressions) of type int can be converted to type sbyte, byte, short, ushort, uint, or ulong, provided the value of the constant_expression is within the range of the destination type.

That doesn't explain why sbyte constant cant be converted to ulong. I don't see reason why it shouldn't

---

and is therefore not allowed to be converted to ulong implicitly because its type is sbyte.

As far as i know, constants are evaluated at compile time, its perfectly fine to implicitly convert (sbyte)127 constant to ulong.

[VBAndCs]

I think the problem is that sbyte, ushort, uint and ulong are rarely used, so they not tested well and there was no push to perfect their work and update the specs.

[VBAndCs]

I think the problem is that sbyte, ushort, uint and ulong are rarely used, so they not tested well and there was no push to perfect their work and update the specs.

[HaloFour]

I think the problem is that sbyte, ushort, uint and ulong are rarely used, so they not tested well and there was no push to perfect their work and update the specs.

I think the spec is quite intentional about these types and their signed/unsigned counterparts. You not liking the behavior doesn't mean that it is poorly designed or haphazard.

[khm1600]

@MkazemAkhgary

That doesn't explain why sbyte constant cant be converted to ulong. I don't see reason why it shouldn't

Why?

From the spec:

Implicit constant expression conversions
An implicit constant expression conversion permits the following conversions:

• A constant_expression (Constant expressions) of type int can be converted to type sbyte, byte, short, ushort, uint, or ulong, provided the value of the constant_expression is within the range of the destination type.
• A constant_expression of type long can be converted to type ulong, provided the value of the constant_expression is not negative.

Implicit numeric conversions
The implicit numeric conversions are:

• From sbyte to short, int, long, float, double, or decimal.

AFAIK, sbyte is neither int nor long and cannot be implicitly converted to ulong.

It shouldn't because the spec does not allow it, unless by not explicitly permitting something, the spec allows all kinds of implementation. (null literal to false and 0, for instance)