Replace core language HexStrings with library entity

[Andrei Alexandrescu via Digitalmars-d]

On 3/16/15 9:29 AM, Baz wrote:
> On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
>> Walter Bright:
>>
>>> Unfortunately, it needs to be a dropin replacement for x"...", which
>>> returns a string/wstring/dstring.
>>
>> This is bad. 99% of the times you don't want a string/wstring/dstring
>> out of a hex string:
>>
>> https://issues.dlang.org/show_bug.cgi?id=10454
>> https://issues.dlang.org/show_bug.cgi?id=5909
>>
>> Bye,
>> bearophile
>
> this is the API that's about to be proposed, it named as suggested by
> A.A., and it handles the two issues you point out:
>
> ---
> public string hexString(string hexData, bool putWhites = false)()
> public string hexString(dstring hexData, bool putWhites = false)()
> public string hexString(wstring hexData, bool putWhites = false)()
>
> public ubyte[] hexBytes(string hexData)()
> public ubyte[] hexBytes(dstring hexData)()
> public ubyte[] hexBytes(wstring hexData)()
> ---

(Drop the "public", this ain't Java.)

I don't see a necessity for the input string having different widths; 
string is enough. There may be a necessity to choose the width of the 
output with changes in function name, e.g. hexWString and hexDString.

That opens the question whether we want only ubyte[] for hex bytes or 
all integral types.

> additionally to x string, a template parameter allows to put raw whites,
> e.g
>
> ---
> assert(hexString!("30 30", true) == "0 1");
> assert(hexString!("30 31") == "01"); // standard x string
> ---

I don't see a need for this.


Andrei