Enhancing hex and binary literal representation

[The-Futurist]

Do others here find it a bit frustrating to be able to write this:

reg &= 0xBF;

but not

reg &= ~0xBF;

where reg is declared as byte.

If there was a way to make the literal be treated as a specific basic type (like byte) this kind of code might be easier to write and look less cluttered than it does today.

So would it not be helpful to extend the notation used for hex literals to allow something like this:

0x8C.b
0x8C.sb
0x8C.s
0x8C.us
0x8C.l
0x8C.ul

This seems like it would be non-breaking and make such code more readable without the mental gymnastics needed to compensate for it being treated as a signed 32 bit int, in cases where we are doing bit manipulation and interacting with hardware and stuff, this would make such code more intuitive.

Thoughts...

[333fred]

The issue is not related to hex or binary literals, they already support all of the suffixes that C# already supports for literal numbers. The issue is that there is no suffix for byte.

[The-Futurist]

The issue is not related to hex or binary literals, they already support all of the suffixes that C# already supports for literal numbers. The issue is that there is no suffix for byte.

Yes, you're right, we already have U and L and UL but no B or UB - that's all that's missing, maybe this is a small ask then.

Of course B and b are legal hexadecimal characters hence my . suggestion, some things that could be simple often aren't.

Perhaps SB or sb for signed byte (char) and UB or ub for unsigned byte...

reg &= ~0xBFub;

But again the ~ expects ints...

[colejohnson66]

Isn't this also an issue because of implicit promotion to int/long in C#? So, even with a suffix, the bitwise negation would implicitly upcast it back to int?

[jilles-sg]

Indeed, a constant of type byte would not help because the ~ operator would convert it to int anyway.

The reason that reg &= 0xBF; works is a bit more subtle. There is a special rule that allows implicitly converting constants of type int to byte, sbyte, short or ushort if they are in range for the destination type.

Therefore, reg &= ~0xBF; does not compile because the constant is out of range (it's negative).

To fix it we need to ensure the constant is in range, such as by ~0xBF & 0xFF or 0xBF ^ 0xFF. I don't see a reasonable way to make reg &= ~0xBF; work.

By the way, this works even for default(int), leading to the situation that byte b = default(int); is accepted but byte b = default(short); is not. Writing default(int) is just a difficult way of writing 0.

[RikkiGibson]

I don't see a reasonable way to make reg &= ~0xBF; work.

It seems like you could do something like analyze the "bounds" of expressions involving constant values and built-in operators. For example, it seems like we should be able to assume that reg <= (reg & 0xBF) always holds, and therefore reg = (reg & 0xBF) is OK.

For signed types, probably a different kind of bounds would need to be inferred, but it might still be doable, I'd have to think more about the representation when it comes to bitwise stuff.

[RikkiGibson]

I have hit this situation, but, I think it's not solved by a literal suffix, because few (or no?) built-in operators take and return bytes. So, there is a need to cast results to byte quite often, or even to unchecked((byte)expr) when a constant value is not in range of byte.

I'm not sure I consider it a problem that we should solve, though. While it can be inconvenient, it does cause me to think more often about what to do with overflow, which is a more frequent occurrence with the smaller numeric types.

[The-Futurist]

The logical operators are all inherently unsigned, there's no concept of a sign for AND, OR, NAND, NOR or NOT (only C#'s >> operator cares about signs).

So something like this should not require acrobatics:

byte reg &= ~0xBF