On 16/03/2015 14:22, Kagamin wrote:
> On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
>> /++/ - If we made /**/ nest, /++/ would be unnecessary
>
> I'd just drop nested comments: block comments and version(none) are good
> enough.

They need to nest in order to allow block comments in documentation blocks.

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)()
---

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

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

Andrei Alexandrescu:

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

I suggest to implement only ubyte[] first. And wait for enhancement requests.

Bye,
bearophile

On 3/16/15 11:54 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> That opens the question whether we want only ubyte[] for hex bytes or
>> all integral types.
>
> I suggest to implement only ubyte[] first. And wait for enhancement
> requests.

At a minimum we need the built-in replacement. -- Andrei

On Monday, 16 March 2015 at 18:58:11 UTC, Andrei Alexandrescu wrote:
>> I suggest to implement only ubyte[] first. And wait for enhancement
>> requests.
>
> At a minimum we need the built-in replacement. -- Andrei

cast(string)hex!"…" works just fine as a built-in replacement (where hex returns an ubyte array).

Why should we repeat the same design mistake if we are going to break people's code anyway?

 — David

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.

BTW, the motivation for x strings is that dumpers often put out results like this:

0000: 80 14  0 12 43 3a 5c 63 62 78 5c 6d 61 72 73 5c    ....C:\cbx\mars\
0010: 74 6f 69 72 2e 63  0 88  6  0  0 9d 37 6e 4f  0    toir.c......7nO.
0020: 88  6  0  0 a1  1 43 56  0 96 4c  0  0  4 46 4c    ......CV..L...FL
0030: 41 54  5 5f 54 45 58 54  4 43 4f 44 45  5 5f 44    AT._TEXT.CODE._D
0040: 41 54 41  4 44 41 54 41  5 43 4f 4e 53 54  4 5f    ATA.DATA.CONST._
0050: 42 53 53  3 42 53 53  7 24 24 54 59 50 45 53  6    BSS.BSS.$$TYPES.
0060: 44 45 42 54 59 50  9 24 24 53 59 4d 42 4f 4c 53    DEBTYP.$$SYMBOLS
0070:  6 44 45 42 53 59 4d  0 99  9  0 a9 d7 11  0  0    .DEBSYM.........
0080:  3  4  1  0 99  9  0 a9 78 10  0  0  5  6  1  0    ........x.......
0090: 99  9  0 a9  0  0  0  0  7  7  1  0 99  9  0 a9    ................
00a0:  0  0  0  0  8  9  1  0 99  9  0 a1 15  e  0  0    ................
00b0:  c  d  1  0 99  9  0 a1 e3 39  0  0  a  b  1  0    .........9......
00c0: 9a  2  0  2  0 91 73  0  0  1 2e 3f 69 6e 63 55    ......s....?incU
00d0: 73 61 67 65 45 6c 65 6d 40 40 59 41 50 41 55 65    sageElem@@YAPAUe
00e0: 6c 65 6d 40 40 50 41 55 49 52 53 74 61 74 65 40    lem@@PAUIRState@
00f0: 40 55 4c 6f 63 40 40 40 5a 10  0  0  0  0 36 3f    @ULoc@@@Z.....6?
0100: 67 65 74 45 74 68 69 73 40 40 59 41 50 41 55 65    getEthis@@YAPAUe
0110: 6c 65 6d 40 40 55 4c 6f 63 40 40 50 41 55 49 52    lem@@ULoc@@PAUIR
0120: 53 74 61 74 65 40 40 50 41 56 44 73 79 6d 62 6f    State@@PAVDsymbo
0130: 6c 40 40 40 5a  7  1  0  0  0  0 95  1  2  0  1    l@@@Z...........

and it's a giant pain to add all the \x notations, besides making it unreadably ugly.

On Monday, 16 March 2015 at 21:40:25 UTC, Walter Bright wrote:
> BTW, the motivation for x strings is that dumpers often put out results like this:

The nice thing about CTFE is it could literally just use that string and snip out the pieces as needed.

I really think users should learn the language more than the library.... if you know the implementation of hexString, you can do so much more with it than if you just know the function name. (this is also a benefit to this kind of function over a built in, of course)

On 3/16/15 3:02 PM, Adam D. Ruppe wrote:
> I really think users should learn the language more than the library....
> if you know the implementation of hexString, you can do so much more
> with it than if you just know the function name. (this is also a benefit
> to this kind of function over a built in, of course)

hexString just being there accessible for inspection is a good argument for its existence. People can use it as inspiration for their own abstractions. -- Andrei