Jarrett Billingsley wrote:
On Tue, Dec 9, 2008 at 12:00 PM, Ellery Newcomer
<[EMAIL PROTECTED]> wrote:
Derek Parnell wrote:
> It is not a bug. A string literal such as "true" is a char[] type (UTF8),
and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]).
Which would then beg the obvious
wchar[] w = "true";
It's a sort of special case. String literals are, by default, UTF-8.
But if you use a string literal in a situation where it can only be
UTF-16 or UTF-32, it's automatically converted.
However if a string literal is used in a context where it can be
multiple encodings, an error results:
void foo(char[] s) {}
void foo(wchar[] s) {}
foo("hello") fails because string literals are implicitly convertible
to both char[] and wchar[], so you have to append either a c or a w to
the literal.
As for why 'wchar[] s = true ? "true" : "false"' doesn't work, it's
because the initializer expression is semantically analyzed before
looking at the destination type. The type of the initializer is
determined to be char[], which is not implicitly convertible to
wchar[].
It can obviously be argued that since the operands of ?: are constant,
the compiler _could_ figure out that they should be of type wchar[],
but that would make the semantic analysis more complicated, and since
appending 'w' to the strings is far easier, it probably won't change
any time soon.
I think the compiler should be smarter. I understand that the compiler
should be simple to allow other implementations to be done easily.
But... I don't think that's true. A D compiler must already instantiate
templates and do compile-time evaluation. Now tell me that's easy! :-P
After all, how many compiler implementors could there be? And how many
users of the language? The language should focus on making it very easy
to program and to avoid this kinds of pitfalls.
