Replace core language HexStrings with library entity

[Baz via Digitalmars-d]

On Monday, 16 March 2015 at 16:45:25 UTC, Andrei Alexandrescu 
wrote:
> 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

I'd like to propose this:

http://dpaste.dzfl.pl/044958878fd9

But after reading D.Nadlinger mind about the whole thing i 
realize that's the opposite the things should be done in the 
opposite way.