Regarding hex strings

foobar foo at bar.com
Thu Oct 18 03:00:54 PDT 2012


On Thursday, 18 October 2012 at 09:42:43 UTC, monarch_dodra wrote:
> On Thursday, 18 October 2012 at 08:58:57 UTC, foobar wrote:
>>
>> 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.
>
> Have you actually ever written code that requires using code 
> points? This feature is a *huge* convenience for when you do. 
> Just compare:
>
> string nihongo1 = x"e697a5 e69cac e8aa9e";
> string nihongo2 = "\ue697a5\ue69cac\ue8aa9e";
> ubyte[] nihongo3 = [0xe6, 0x97, 0xa5, 0xe6, 0x9c, 0xac, 0xe8, 
> 0xaa, 0x9e];
>
> BTW, your data2 doesn't compile.

I didn't try to compile it :) I just rewrote berophile's example 
with 0x prefixes.

How often do you actually need to write code-point _literals_ in 
your code?
I'm not arguing that it isn't convenient. My question would be 
rather Anderi's "does it pull it's own weight?" meaning does the 
added complexity in the language and having more than one way for 
doing something worth that convenience?

Seems to me this is in the same ballpark as the built-in complex 
numbers. Sure it's nice to be able to write "4+5i" instead of 
"complex(4,5)" but how frequently do you actually ever need the 
_literals_ even in complex computational heavy code?


More information about the Digitalmars-d mailing list