missing HexString documentation

[Steven Schveighoffer]

On 2/8/18 3:49 PM, Walter Bright wrote:
> On 2/8/2018 10:42 AM, Steven Schveighoffer wrote:
>> On 2/8/18 1:25 PM, Walter Bright wrote:
>> "abc" is an array (it's an immutable(char)[]). There's no reason why 
>> ['a','b','c'] should be different than "abc" (other than the hidden 
>> null character, which is irrelevant here).
> 
> ['a','b','c'] is mutable, a string literal is immutable.

OK.

     alias IC = immutable char;
     ubyte[3] x = [IC('a'), IC('b'), IC('c')];

works just fine.

> 
> 
>> Perhaps the fact that using a string rather than an array causes code 
>> to fail should be addressed?
> 
> 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

>> How can this be a huge simplification? I mean you already have code 
>> that parses hex characters in a string array, all you need is one flag 
>> that assumes all character pairs have been preceded by \x. I think 
>> this will save probably 4 or 5 lines of code?
> 
> hexStringConstant() was 79 lines of code, not including comments and 
> blank lines.

My mistake, I assumed the code to parse hex digits would be reused 
between both string parsing with \x escapes and the hex string parser.

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.

> I also showed how:
> 
>     x"deadbeef"
> 
> can be replaced with:
> 
>     hexString!"deadbeef"
> 
> with no overhead. 

I wouldn't call invoking CTFE "no overhead"

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

> If you hate typing hexString, you can always write:
> 
>     alias x = hexstring;
> 
> and then you've got:
> 
>     x"deadbeef"
>     x!"deadbeef"
> 
> which seems an inconsequential difference. (The generated code is the 
> same.)

Again, this is about the compile time penalty.

>> It also doesn't preclude at all someone writing library code to make 
>> their own custom string syntax.
> 
> You're right it doesn't. But people don't do it, because it is neither 
> obvious that D can do such a thing (it relies on a combination of 
> features)

This isn't really about having hexString in phobos, I think it's fine to 
have it, even if it's redundant, since it can be more customized than a 
builtin language feature. All I was saying is that the language feature 
and the library function are not mutually exclusive.

> nor is it obvious how to do it correctly (as the earlier 
> hexString implementation shows and nobody seemed able to fix it but me).

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.

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.

> What Phobos provides is working, professional quality code that should 
> serve as a user resource for "how to do things and how to do them right".

It worked before, pretty much at the same performance as it does now, 
the mitigating features (using string literals instead of array 
literals, splitting the implementation into hand written functions to 
avoid the D template penalty) are a good demonstration at how much work 
we have to do still on the CTFE front.

> I.e. having hexString as a library function is a good advertisement for 
> what D can do. After all, how many languages can do this sort of thing?

And nothing has changed here, it's still a library function, as it was 
before. I agree, it's great to have the ability to do library functions 
that can do compiler features. But if you already have the compiler 
feature, I don't see why we should remove it because a slower library 
version exists.

If we did not have the feature in the language, and we were talking 
about adding it, I'd totally be on the other side. 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.

-Steve