missing HexString documentation

[Steven Schveighoffer]

On 2/11/18 4:48 PM, Walter Bright wrote:
>> 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've never seen a hex dump where the individual nibbles were separated 
by spaces in odd ways.

In other words, what I was saying is that:

"\x12\x34"

could be written as:

x"1 23 4"

which is... odd. What it does is make it so you can't reuse the parsing 
code inside the string escape processor to handle the hex string, 
necessitating an extra 80-line function.

>> I wouldn't call invoking CTFE "no overhead"
> 
> It is no overhead in the generated code.

It's overhead that adds up, memory and time-wise. Really, the memory 
concerns of using CTFE are a bigger problem than the extra tenths of a 
second of compile time.

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

Or a very large hex string (very feasible). But very true that there are 
mitigating methods that can be used.

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

In the past, we have not broken code, even when it depends on known 
bugs, if we can help it. But maybe if we can fix the bug I filed above, 
it won't matter.

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

Essentially, you have instantiated the template eagerly, which kind of, 
sort of, defeats the purpose of a template. Though, you still do get the 
benefit of code generation, it's just not an "open-ended" template that 
you can instantiate with any type. Perhaps we should be using this 
pattern all throughout phobos where strings are involved, since there 
are ever only 3 types you instantiate with.

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

The solution isn't incredible, but the fact that this solution is the 
only way to get the CTFE-only code not to creep into your object file is 
a bit dissatisfying. You would think the linker/compiler would not 
inject the unused function into the object file without having to do this.

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

I think this is due to functions-that-aren't-used being included.

In other words, there was nothing inherent in the old library code that 
created a requirement for druntime to be included.

The bloat is also a deficiency of the compiler, not the code itself.

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

I missed the discussion (there are times where I can't pay attention to 
D for a month or so due to being busy). But in any case, sure I 
understand the "why", but the cost/benefit for me was not high enough, 
and in some aspects, it is all cost, no benefit.

In any case, it isn't a decision that needs to be reversed, as there is 
a workable solution in the library, even if it's sub-optimal. I just 
think it's not as beneficial as has been reported.

-Steve