Suggest adding suffixes to the types "short, ushort, byte, sbyte"

[nczsl]

Suggest adding suffixes to the types "short, ushort, byte, sbyte", just like the float suffix is f and the double suffix is d. This can make it easier to use these types for calculations and avoid the hassle of converting to int before calculation,

short x1,x2;
short x3=x1+x2; // error CS0266
//Similar situation

[huoyaoyuan]

This can make it easier to use these types for calculations and avoid the hassle of converting to int before calculation

It won't. There's no arithmetic operators defined for the small numbers. No matter how you get two values of short, the operators will always upcast to int.

[colejohnson66]

To expand: the IL that C# compiles into is a stack language. The only integer types it supports on the stack are int32, int64, nint/IntPtr, and their unsigned counterparts. All integer operations must result in one of those six types.

[jilles-sg]

The IL operations themselves are not really relevant to this. For example, C# allows assigning one short variable to another, which goes through a 32-bit integer on the IL stack. Technically, the compiler could implement arithmetic on short values by inserting conv.i2 or similar instructions when the difference could be detected, such as when comparing, dividing or converting to a larger type. This would probably be slower on the kinds of machines C# runs on and more likely to cause bugs due to unexpected overflow.

Rather, C# deliberately converts smaller integers to int when performing arithmetic (like Java and C before it). This is probably to avoid unexpected results when doing things like

short a = 1000;
short b = 2000;
int product = a * b;

A different language could avoid this problem and still provide arithmetic on smaller integers by not having implicit widening conversions between integer variables (using an unadorned integer constant as any fitting integer type would be fine).