Remove the implicit conversions associated with bitwise operators

[The-Futurist]

When we use bitwise operators with sbyte, byte, short, ushort, or char operands, the language forces each operand to be converted to int.

This makes sense for arithmetic operators (where the bit length of results might increase) but really doesn't make any sense for bitwise operators.

This refuses to compile today

byte result = byte1 | byte2;

and must be expressed as

byte result = (byte)(byte1 | byte2);

This verbosity seems unnecessary and I wonder if the language team would consider reviewing this behavior.

If these operators were modified to not promote these types to int then the casts could be eliminated. It seems too, that this would be a non-breaking change which is why I am raising it (if it were a breaking change then of course it becomes a much more contentious suggestion).

I've been encountering this a lot recently because I'm writing C# code that manages IoT devices and there's a lot of byte registers and stuff that need specific bits setting/resetting and it quickly becomes cluttered with all the casts.

I wonder if there's a cost too in converting (for example) byte to int in these expressions, if there is then that cost could be eliminated.

Note too that the compound bitwise assignment operators do not need casts and this seems inconsistent for no good reason, here register and datum are each of type byte and this compiles fine:

register &= datum;

whereas this does not:

register = register & datum;

[huoyaoyuan]

There is nothing to "remove". Instead, there's no operator defined on small integers. The implicit conversion happens before the operator. To remove the conversion, there needs to be new operators introduced for byte.

I wonder if there's a cost too in converting (for example) byte to int in these expressions, if there is then that cost could be eliminated.

Modern CPU only provides operators on int32. The casts will remain the same after lowering.

[sab39]

Could this be achieved with extension operators if they were defined directly on byte, or would the built in operator on int still take precedence even though it needs an implicit conversion to be applicable?

[333fred]

Builtins will take precedence, we don't even search for extensions unless standard lookup fails.

[colejohnson66]

Modern CPU only provides operators on int32.

Not true. x86, for example, provides (s)byte, (u)short, (u)int, and (u)long operators. RISC-V doesn't, but that's not common enough to provide an argument.

The real issue here is that the CIL mandates all integer slots on the stack be 32-bits or bigger, so C# automatically promotes anything smaller. conv.u1 doesn't replace the top-most slot with an 8-bit integer — no, it casts it to an 8-bit integer, then back to a 32-bit integer for the stack.

[huoyaoyuan]

Not true. x86, for example, provides (s)byte, (u)short, (u)int, and (u)long operators.

The short operators are practically never used in 32/64bit mode.

[theunrepentantgeek]

This would be a breaking change.

Consider this code:

var result = byte1 | byte2;

At the moment, result has type int.

If this change went forward, result would havce type byte.

This change might result in different overload selection, or in under/over-flow happening at different boundaries in later expressions.

[The-Futurist]

That's a good observation. Having said that, that example is equivalent (shorthand) to:

int result = byte1 | byte2;

So if the type inferred for the var were to continue to be int it wouldn't be a braking change, the inferred type in this particular situation could remain as int.

If the language team were willing to do that, then that concern could be eliminated...

[theunrepentantgeek]

Referring back to the original request:

If these operators were modified to not promote these types to int then the casts could be eliminated.

If this happened, the natural type of byte1 | byte2 would be byte, and the inferred type of

var result = byte1 | byte2;

would result in it being equivalent to

byte result = byte1 | byte2;

This is how var works: the inferred type of a var statement is the type of the expression result on the righthand side.

This would be, as I said, a breaking change.

For

var result = byte1 | byte2;

to compile as

int result = byte1 | byte2;

requires the righthand side to have type int - which is what the compiler currently does.

[yaakov-h]

Not necessarily. I'm not sure it would work here, but target-typing is a thing and might be useful here.

i.e. if the receiver is byte, the result is byte. if the receiver has no known type, it can default to int.

the same way that if the receiver is Span<T> the the result of a stackalloc is a Span, otherwise it defaults to T*, or that if the receiver is List<T> then the result of [ ... ] is List<T> and not T[]...

[The-Futurist]

Again you raise excellent points. I'm of the opinion that the inference made by var can be maintained while at the same time allowing a bitwise operator with byte arguments (for example) to yield a byte result.

So long as var behaved as it does today (an implementation issue) one could still allow

byte result = byte1 | byte2;

So I agree that this is an important point to maintain backward compatibility, but I think it can be maintained while at the same time allow the above code.

If var is used (like in your example) then maintain compatibility with the original rules but when not using var allow the type to not need promoting to int.

There are a host of details of course but this is not in and of itself unusual with languages. The core of my position is that operators like | and & etc never ever require any kind of type promotion because - unlike arithmetic - the bit length of the result can never exceed the bit length of the longest (in terms of bits) operand.

[AartBluestoke]

while you are right that in abstract "core of my position is that operators like | and & etc never ever require any kind of type promotion"

1. it /is/ currently type promoted, Console.WriteLine((byte1|byte2).GetType()); returns System.Int32 - forcing/allowing the path for byte1 | byte2 to be 'byte' impacts many places - eg f(a|b) could now select a different function, anything which uses sizeof(x) could now return 1 instead of 4.
2. the language is exceeding unlikely to write a rule that says "var is always the type of the other side of the equals, except when certain bitwise operators want it to be byte, then it is implicitly widened to (signed)Int32.
3. atomic operations on modern hardware is only guaranteed at a word level - setting the first byte of an int and the second byte of an int by (non-aligned) address has to be done carefully, force-casting to an int guarantees certain accuracy considerations.

[The-Futurist]

Yes, these are important considerations.

Note this though:

byte result = 0;

result &= 0xA3;

This compiles precisely because the language does have specific rules for these cases. So a &= b is not semantically identical to a = a & b; which is odd since the documentation says they are equivalent.

In these cases an implicit cast is added to the assignment.

Now look at this:

byte result = 0;
byte X45 = 0x45;       // 1 - int to byte, no cast
byte X3F = 0x3F;       // 2 - int to byte, no cast.

result = 0x45 | 0x3F;  // 3 - Works
result = X45  | X3F;   // 4 - Fails

Assignment 3 compiles but 4 does not! (I know "why" I understand the rules). Here we have two int values in an OR expression and assigned to a byte result without an explicit cast but in the latter we have only byte values yet need an explicit cast!

Furthermore 1 and 2 compile also yet we have a int being assigned to a byte with no explicit cast.

In 3 and 4 though, it is clear in each case that the result can never exceed the size of a byte so why treat them differently.

I would think the operands of the bitwise infix operators should only convert an operand's type if it is smaller than the other operand's type.

So byte and byte has byte result, but byte and uint has a uint result.