A more readable way to define hex literals

[OriginalGriff]

I saw this on CodeProject: https://www.codeproject.com/Messages/6014760/Well-gee-golly-C-done-gone-and-got-fancy-if-you-us And assume that it was the equivelant of this:
byte[] data = 0xFE'DC'BA'98;
vs the original
byte[] data = {0xFE, 0xDC, 0xBA, 0x98};

It isn't, it's the equivelant of the numeric literal underscore added at V7:
long i = 1_000_000_000_000;
vs
long i = 1000000000000;

But it got me thinking how much more readable (and thus maintainable) it would be if hex literals / byte collections could be written in that way, particularly when you need to communicate with external devices, or generate template data for binary formatted files:
byte[] poll = 0x01'00'00'02'FF'FF'FF'FF'03;
vs
byte[] poll = {0x01, 0x00, 0x00, 0x02, 0xFF, 0xFF, 0xFF, 0xFF, 0x03};
for example.

Basically, the quote character extends the base specifier to produce a byte stream in a more compact and readable form.

[TahirAhmadov]

You can get most of the way there today:

static byte[] HexToBytes(string s) { ... }
byte[] pol1 = HexToBytes("01'00'00'02'FF'FF'FF'FF'03");

[yaakov-h]

This incurs a parsing cost at runtime that a language feature wouldn't.

I'd also expect as a language feature it could do that fun ReadOnlySpan optimisation too.

[OriginalGriff]

@yaakov-h I'd agree - run time parsing would be unacceptable because it introduces potential run time errors that are an anathema to a strongly typed language. Catch 'em at compile time! :D

[TahirAhmadov]

I thought about that. For optimal performance, deterministic functions will be able to bake the bytes into the program. I'd rather see that feature get done, instead of yet another one-off solution for byte arrays.

[ufcpp]

I have built a source generator to do this.
https://github.com/ufcpp/StringLiteralGenerator/blob/725058bc5c81aec442985b7cca7955e85130cabf/samples/StringLiteralSample/Program.cs#L15

[colejohnson66]

The UTF8 one isn’t strictly necessary now that UTF8 literals exist.