Define overload math operators for types smaller than int

[ghost]

Why have we to use cast to do basic math operations between bytes, short, and ushort? I think it will make things easier to define overload operators for those types.
For example:

short x = short.MaxValue;
ushort z =x + x;

this code will not even cause an overflow, but C# doesn't accept it. It only accepts:

short x = short.MaxValue;
ushort z =(ushort)(x + x);

[CyrusNajmabadi]

Why have we to use cast to do basic math operations between bytes, short, and ushort?

Because of hte language specification: https://github.com/dotnet/csharplang/blob/master/spec/expressions.md#numeric-promotions

Define overload math operators for types smaller than int

This could break huge swaths of programs out there. Any program that depends on the current numeric promotion logic would not have differing behavior.

[ghost]

@CyrusNajmabadi

This could break huge swaths of programs

I can't imagine that. The new change will allow to get rid off the casting, so, the existing code that uses that casting can live on. Do you have any examole for that break?

[CyrusNajmabadi]

I can't imagine that. The new change will allow to get rid off the casting

Sorry, i don't know what you're proposing then. Your title is:

Define overload math operators for types smaller than int

So i assumed this meant defining operators like short +(short v1, short v2).

That would clearly be a breaking change. If that's not what you want, then what are you asking for?

[tannergooding]

@MohammadHamdyGhanem, as mentioned in https://github.com/dotnet/corefx/issues/30363#issuecomment-397050032, there is no way to guarantee that short + short will produce an unsigned value (ushort). As @karelz mentioned

-1 + 0 would silently become ushort.MaxValue.

As for others, operators, it isn't clear where you expect the cast to happen:

ushort = byte + byte should not automatically cast either IMO, because it is not clear if the code wants to first cast to ushort and then add (255+255 = 510), or add with byte limitations (incl. underflow) and then cast to ushort (=254).

The rules today are very clear on what happens, and forcing you to add in an explicit cast ensures you understand those semantics.

[ghost]

@CyrusNajmabadi @tannergooding
I answered in this comment: https://github.com/dotnet/corefx/issues/30363#issuecomment-397057890

C# Converts operands to int first, so the result is int, which makes a problem to implicitly cast it back to the desired type. So, ushort = byte + byte becomes ```ushort = int'''. This int is safe to be cast to ushort, so I can say: if neither of the two operands is int, it is safe to do implicit cast.
The ushort class can have these operator:

public static ushort implicit operator + (ushort x, ushort y)
   => ushort((int)x + (int)y);

so, ushort = byte + byte should call this operator. There is some work needed on the C# side, to decide to call ushort.OppAdd not byte.OpAdd based of the le4ft hand variable type. This woll make it behave as we expect. If any programmer have anything else in mind, he can do explicit casting.

[CyrusNajmabadi]

public static ushort implicit operator + (ushort x, ushort y)
   => ushort((int)x + (int)y);

This would be a breaking change. You would get a different result for two ushorts added together. So:

ushort a = ...;
ushort b = ...;
var c = a + b;  //<-- this will change meaning.

[CyrusNajmabadi]

Note: C# could have had operators like this in V1. Then things would have worked in the manner you want, and would have had well-defined semantics taht people could depend on. However, it went with numeric promotion in V1 (for many different reasons, but not actually relevant why right now). And changing htat, would definitely be breaking. So it can't change now, even if it would be beneficial for your needs.

Note: if you want these sorts of operators, then you can define your own types that behave this way. For example:

struct MHG_UShort
{
      private readonly ushort val;
      // define your operators
}

Now you can use that instead of ushort and you can have the semantics you want for your own operators. You would not need to define numeric promotion for your own types.

[CyrusNajmabadi]

This woll make it behave as we expect.

It will not behave as i expect it (or anyone used to C# for the past 15 years). Numeric promotion is what i expect... :)

[ghost]

OK. Seems I need to write my own basic types, with implicit conversions to anf from intrinsic types!
I will do that.
But, in the var situation, C# can call the int.opadd as you expect. I said c# should decid which operator to use depending on the left hand type. If it is not there, then the old behavior is expected. Still not breaking any thing 😀
Thanks.

[CyrusNajmabadi]

OK. Seems I need to write my own basic types,

This is def the recommendation when you want to carve out types that have differing semantics from what is already there :)

Thanks.

Any time!

But, in the var situation, C# can call the int.opadd as you expect. I said c# should decid which operator to use depending on the left hand type.

So you need a declared type for C# to determine what to do? Isn't that what you get with (ushort)(a + b)?

[ghost]

@CyrusNajmabadi

Isn't that what you get with (ushort)(a + b)?

That is half the story, but waht brings this now, is a situation where Iwas sending (ushort + ushort) to a ushort param :).
The type inference can be extended in the opisite direction, so c# can detect that the result of an arithmitic operation is expected to be of type X where X is not integer. if both operands are of type X or can be implicitly casted to type X and there is no explicit cast to types other than X, then C# can do the arithmitic operation between (X and X) and return an X type. But if the return type is to be infered, then C# stick with the same old behaviour.
I think this worth some little analysis and if it is safe and will not breake anything, so why we can't have a smarter C# code?

[ghost]

Besides:
C# editor can suggest some sultions to solve:

            byte x = 1;
            byte y = 2;
            ushort z = x +y;

On top of them:
cast the result to ushort: var z = ushort(x + y);

[CyrusNajmabadi]

C# editor can suggest some sultions to solve:

PR's welcome. I can guide you on how to do ths if you want.

[ghost]

I know you are that kind. Thanks.
Add it to the ToDo list :)

[CyrusNajmabadi]

I don't think keepign an unbounded list of work that is unlikely to get done is a good idea. If you'd like this feature, my recommendation woudl be to provide it. Otherwise, there's not much chance this will happen :)

[ghost]

I'm still stuck with Verex, and now it has a NuGet. I discovered some bugs and fixed them, so I can say V1.2 is stable until someone reports an issue. Now, I had to review two chapters about Collections and files (that should bave been done three month ago!) So, you can expect new issues about these two topics soon :) .
Forgive me, but things are messy enough for me right now! I want to do many things, but I not that time-organized person!
thanks.