missing HexString documentation

[Steven Schveighoffer]

On 2/7/18 12:01 PM, Adam D. Ruppe wrote:
> On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
>> For the same reason why octal literals have been deprecated years ago:
>>
>> https://dlang.org/deprecate.html#Octal%20literals

Not even close. Octal literals are a disaster, because putting a leading 
0 should never change the base of a number. Basically, causing bugs 
everywhere for a small corner case in the real world.

The octal literal library solution is good, and it's fine to have 
something in the library for this, as octal values are extremely rare to 
need.

But in this case, there is no ambiguity. x"..." is not obvious syntax 
for anything else. Not only that, but the code to parse hex data into a 
string is still in there for "\x..." So we didn't even remove anything 
significant.

>> The library solution works as well and it's one of the features that 
>> are rarely used and add up to the steep learning curve.

How so? If you see a hex string literal, you look it up, and now your 
learning curve is over.

> That's actually not the reason given. Octal literals had the stupid 
> leading 0. We should have just made it 0o instead.

This has its own problems (e.g. 0O), but definitely would have solved 
the issue. However, octal numbers are way less common than strings of 
hexadecimal data bytes.

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. Not only that, but the removal from 
the language doesn't really buy us any savings in the compiler. It's 
basically removing things for the sake of removing them.

> Similarly, I think the mistake of hex strings is that they are typed 
> char[] instead of ubyte[]. Otherwise... they work ok.

Yes, they would be better as ubyte[], but this problem is not the end of 
the world. I don't consider it the same level as thinking 012 is 12.

-Steve