misleading syntax difference between performing math with big integers and small integers.

[YV99king]

Description

when adding (and probably performing other math operations on) small numbers (e.g. byte, short) a cast is required as the addition is done using the int add operator. that cast is not necessary with big numbers (e.g. int, long) because they have their own add operator. that cast is optimized away later in the process so it will not effect performance but it will be looking like it would to new developers.

Reproduction Steps

1. create a new console application and replace the program.cs contents with:

byte ByteAddition(byte a, byte b)
{
    return (byte)(a + b);
}

int IntAddition(byte ai, byte bi)
{
    return ai + bi;
}

ByteAddition(1, 2);
IntAddition(3, 4);

2. check the actual machine code generated (e.g. using visual studio's disassembly view) and check whether the code is different in ByteAddition versus IntAddition

Expected behavior

if the code is anyway exactly the same a cast wont be necessary.

Actual behavior

a cast is necessary.

Regression?

no, it was not different in past versions

Known Workarounds

as stated above the actual executed code is exactly the same only the syntax is a bit misleading

Configuration

.net 8
windows 10
x64
i dont know if on different configuration the performance will be different but i dont think so

Other information

a good solution will probably be just making the the operators from from IAdditionOperators<TSelf, TOther, TResult> accessible thou unfortunately i do not know how the .net framework is working well enough to judge.

[stephentoub]

According to the C# specification, a Byte plus a Byte produces an Int32, hence why the cast is necessary.

[stephentoub]

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#12473-binary-numeric-promotions

12.4.7.3 Binary numeric promotions

"Binary numeric promotion occurs for the operands of the predefined +, -, *, /, %, &, |, ^, ==, !=, >, <, >=, and <= binary operators. Binary numeric promotion implicitly converts both operands to a common type which, in case of the non-relational operators, also becomes the result type of the operation. Binary numeric promotion consists of applying the following rules, in the order they appear here:
...
Otherwise, both operands are converted to type int."

[HaloFour]

Actually I think the specification doesn't provide built-in addition for byte at all, and the operands are promoted to int.

https://ecma-international.org/publications-and-standards/standards/ecma-334/

Section 12.10.5 Addition Operator

The predefined addition operators are listed below. For numeric and enumeration types, the predefined addition operators compute the sum of the two operands. When one or both operands are of type string, the predefined addition operators concatenate the string representation of the operands.

• Integer addition:
int operator +(int x, int y);
uint operator +(uint x, uint y);
long operator +(long x, long y);
ulong operator +(ulong x, ulong y);

Either way this has been the behavior of C# since 1.0.

[YV99king]

@stephentoub just a bit before that, in section 12.4.7.1 it explicitly says:
"§12.4.7 and its subclauses are a summary of the combined effect of:

• the rules for implicit numeric conversions (§10.2.3);
• the rules for better conversion (§12.6.4.7); and
• the available arithmetic (§12.10), relational (§12.12), and integral logical (§12.13.2) operators."

and
"...Numeric promotion is not a distinct mechanism, but rather an effect of applying overload resolution to the predefined operators. ..."

@HaloFour that was the exact behavior that was pointed out as confusing

[HaloFour]

Maybe, but it was an intentional design choice and one that was made probably 25 years ago. So at this point the behavior cannot be changed. The language team thought that it was more important to avoid accidental overflow on uncommon integral types than it was to achieve syntactic consistency.

[jnm2]

As the answer mentions, there's a rule in the C# language that byte values (and sbytes, shorts, etc) are converted to ints before adding.

Imagine for a second that this was not the case. In this alternate universe, when you write:

byte a = 100;
byte b = 200;
Console.WriteLine(a + b);

you would get the output 44, or an overflow exception if the code is in a checked context.

Even worse, this would behave the same way, yielding 44 or throwing:

int c = a + b;

This overflow behavior happens with much smaller numbers for byte, short, etc than it does for int. My guess is that this is optimizing for the common cases: it's common for byte and short values to reach near the maximum value for the data type, and it's less common for int values to do so.

So, in this alternate universe, it would have become best practice to always cast smaller integer types to int anyway: (int)a + b. In the current universe, the language is applying this best practice without cluttering up your code.

[jnm2]

You can access the overflowy behavior if you use generic math, though, because byte implements IAdditionOperators<byte, byte, byte> and not IAdditionOperators<byte, byte, int>:

using System;
using System.Numerics;

byte a = 100;
byte b = 200;
Console.WriteLine(Add(a, b)); // 44

static T Add<T>(T a, T b) where T : IAdditionOperators<T, T, T>
{
    return a + b;
}