On Thursday, 18 October 2012 at 14:29:57 UTC, Don Clugston wrote:
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).
I don't see how that detail is relevant to this discussion as I
was not arguing against string literals or array literals in
general.
We can still have both (assuming the code points are valid...):
string foo = "\ua1\ub2\uc3"; // no .dup
and:
ubyte[3] goo = [0xa1, 0xb2, 0xc3]; // implicit .dup
