missing HexString documentation

[Adam D. Ruppe]

On Wednesday, 7 February 2018 at 18:59:38 UTC, Steven 
Schveighoffer wrote:
> Not even close. Octal literals are a disaster, because putting 
> a leading 0 should never change the base of a number.

I agree the leading 0 is terrible. But that's not the real 
question here: it is 0o100 vs import std.conv. Note it isn't the 
syntax - octal!100 is quite nice to me - but rather the 
requirement to import.

That is why it isn't used in druntime... and low level code 
interfacing with external OS or hardware APIs are the most common 
place for octal, and also where we can't use it. I fear hex will 
fall into the same pit.

> This has its own problems (e.g. 0O)

That's why I specifically wrote `0o`. I wouldn't allow `0O`, just 
like D doesn't allow `1l`: "Error: lower case integer suffix 'l' 
is not allowed. Please use 'L' instead"

> The difference for me isn't how the problem is solved, but that 
> there was a problem for octals (error prone sinister errors) 
> but there isn't/wasn't one for hex strings.

You and I are on the same side :) I also think they should stay 
(I just want to see them retyped as immutable(ubyte)[] instead of 
immutable(char)[], we always cast anyway).

I'd repurpose the library hexString to actually read in hex dump, 
stripping offsets, etc, off. Demonstrate that you can strip other 
stuff from the string with CTFE as an example of what we can do 
so people can customize that (that's a big advantage of the 
function over the literal btw, you can feed stuff through ctfe 
modifier functions before it is parsed. Can't do that with a 
literal!)

But also keep the x"" literal for the simple cases we already 
have.