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