Issues with constants, and inout (was Real World usage of D, Today)

[Oskar Linde]

Frits van Bommel wrote:
> kris wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> kris wrote:
>>> [about implicit conversion rules]
>>>>         void write (char[] x) {printf("char[]\n");}
>>>>         void write (wchar[] x) {printf("wchar[]\n");}
>>>>         //foo.write ("asa");
>>>> And this, of course, compiles. It's a PITA though, and differs from 
>>>> the rules for other constants.
>>> I talked to Walter about this and it's not a bug, it's a feature :o). 
>>> Basically it's hard to decide what to do with an unadorned string 
>>> when both wchar[] and char[] would want to "attract" it. I understand 
>>> you're leaning towards defaulting to char[]? Then probably others 
>>> will be unhappy.

A slight inconsistency here is that:

foo("test");

gives a syntax error, while:

auto t = "test";
foo(t);

compiles and selects the char[] overload. Also:

void bar(T)(T x) { foo(x); }
...
bar("test");

compiles and selects the char[] overload.

> It's a bit more complicated with character literals than just defaulting 
> to 'char':
[snip typeof('e') == char, typeof('é') == wchar, ...]]
> So it defaults to the *smallest* character type that can hold it in one 
> element.
> Pretty cool, actually.

A problem related to this, that might actually warrant a bug report, is 
that given:

char[] str = "abcd";

str ~= 'e';
writefln(str);

Is OK, while

str ~= 'é';
writefln(str);

Generates an invalid UTF-8 string ant gives the runtime "Error: 4invalid 
UTF-8 sequence"

It seems like the wchar 'é' gets int-promoted to 0xE9 that is different 
from the char[] (utf-8) representation of "é", that would be x"C3 A9".

-- 
/Oskar