Regarding hex strings

[Don Clugston]

On 18/10/12 10:58, foobar wrote:
> On Thursday, 18 October 2012 at 02:47:42 UTC, H. S. Teoh wrote:
>> On Thu, Oct 18, 2012 at 02:45:10AM +0200, bearophile wrote:
>> [...]
>>> hex strings are useful, but I think they were invented in D1 when
>>> strings were convertible to char[]. But today they are an array of
>>> immutable UFT-8, so I think this default type is not so useful:
>>>
>>> void main() {
>>>     string data1 = x"A1 B2 C3 D4"; // OK
>>>     immutable(ubyte)[] data2 = x"A1 B2 C3 D4"; // error
>>> }
>>>
>>>
>>> test.d(3): Error: cannot implicitly convert expression
>>> ("\xa1\xb2\xc3\xd4") of type string to ubyte[]
>> [...]
>>
>> Yeah I think hex strings would be better as ubyte[] by default.
>>
>> More generally, though, I think *both* of the above lines should be
>> equally accepted.  If you write x"A1 B2 C3" in the context of
>> initializing a string, then the compiler should infer the type of the
>> literal as string, and if the same literal occurs in the context of,
>> say, passing a ubyte[], then its type should be inferred as ubyte[], NOT
>> string.
>>
>>
>> T
>
> IMO, this is a redundant feature that complicates the language for no
> benefit and should be deprecated.
> strings already have an escape sequence for specifying code-points "\u"
> and for ubyte arrays you can simply use:
> immutable(ubyte)[] data2 = [0xA1 0xB2 0xC3 0xD4];
>
> So basically this feature gains us nothing.

That is not the same. Array literals are not the same as string 
literals, they have an implicit .dup.
See my recent thread on this issue (which unfortunately seems have to 
died without a resolution, people got hung up about trailing null 
characters without apparently noticing the more important issue of the dup).