On 18/10/12 17:43, foobar wrote:
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
That doesn't compile.
Error: escape hex sequence has 2 hex digits instead of 4
