missing HexString documentation

[Steven Schveighoffer]

On 2/7/18 3:24 PM, Adam D. Ruppe wrote:
> 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.

So you think it should go into druntime? I don't see why it wasn't in 
there in the first place to be honest.

But there is no "decision" on whether to import or not, it's not 
possible in druntime to import from phobos. So saying the lack of use of 
octal in druntime is somehow a detraction on the import is incorrect. If 
you could have imported std.conv in druntime, it would have been done.

>> 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"

I'm still not in love with the little-o syntax, but this definitely 
would be necessary.

>> 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).

To me, it is a shortcut for specifying hex for every character. The cast 
isn't that horrible, and probably can be abstracted away into a function 
if you want.

-Steve