missing HexString documentation

[Walter Bright]

On 2/11/2018 6:09 AM, Steven Schveighoffer wrote:
> On 2/8/18 3:49 PM, Walter Bright wrote:
>> That would be a language change proposal or bug report. By all means, please 
>> do so.
> 
> https://issues.dlang.org/show_bug.cgi?id=18420

Good!


> I also notice that hex strings are not simply equivalent to strings with \x in 
> them -- the latter is more constrained, as it must be a pair of hex digits per 
> \x. hex strings allow spaces between them.

The idea was to be able to cut&paste text from things like hex dumps, which 
include whitespace formatting.


> I wouldn't call invoking CTFE "no overhead"

It is no overhead in the generated code.


> I tested it out, and generating a hex string of about 600 bytes took 3x as long 
> as using builtin hex strings.

That's only a potential issue if you've got a very, very large number of hex 
strings. And if you do, those strings can be put in a separate module and 
compiled separately.


> Again, this is about the compile time penalty.

Ok.


> Well, nobody asked :) Besides, it's still not "fixed", as it has the same poor 
> performance as the previous version. And the new version has broken existing code.

It didn't break code that used x"deadbeef", it broke code that used the broken 
hexString.


> What the update shows is that you have to jump through incredible hoops to get 
> the compiler not to include your compile-time only generation code in the 
> resulting binary.

With a language that supports both templates and separate compilation, this will 
always be an issue.

The solution here is not "incredible", it is just not obvious.


> And nothing has changed here, it's still a library function, as it was before.

What's changed is it works now with -betterC, and it doesn't produce bloat in 
the executable.


> But if you already have the compiler feature, I don't see why 
> we should remove it because a slower library version exists.

It was not an arbitrary and capricious decision, and the rationale behind it was 
presented here multiple times. If you are not convinced, that's cool, but the 
"why" should be pretty clear.


> In fact, it's a motivating factor to make 
> CTFE code compile faster as it takes away arguments of adding more things to the 
> compiler.

I agree that speeding up CTFE will make it more useful.