ambiguation between char[] and dchar[]

[Oskar Linde]

mandel skrev:
> Hi,
> 
> recently I stumbled over the problem where I call put("hello") on a library class
> but got something equivalent to this:
> Test.d(158): function Test.put called with argument types:
>         (char[4])
> matches both:
>         Test.put(dchar[])
> and:
>         Test.put(wchar[])
> 
> The reason is obviously that class Test implements put(char[] s) and put(dchar[] s) but also put(wchar[] s).

> Interestingly put(wchar[] s) isn't considered as ambiguous.

This is a flaw in DMD's error reporting. It only reports the two first 
ambiguous matches. I've been confused by that before.

> The simple solution would be to call put("hello"c), but it's also quite tedious.
> I tend to forget is as often as the ';' behind class definitions in C++.
> 
> I think the default interpretation of an string should be char[]
> as the compiler output suggests "(char[4])", but apparently doesn't care about.

I agree. This issue has been on the ng several times in the past. 
Different suggestions has been aired such as making the file's current 
encoding (utf-8,utf-16,utf-32) define the preferred type for char 
literals, to make char literals always prefer the char[] overload.

I strongly prefer making char literals always pick the char[] overload. 
Changing the source code encoding should not affect its behavior imho.

In fact, I would like to make a suggest a slightly different fix to this 
problem, for D 2.0.

- Make string literals be dynamic instead of static arrays. I.e. 
invariant char[], instead of invariant char[n].

There is no loss of function, but it will resolve several issues:

1. ambiguous overload of foo(char[]), foo(dchar[]), foo(wchar[])

2. template function issues, such as:

void foo(T)(T x) {...}

foo("a"), foo("ab"), foo("abc"), foo("abcd"), foo("abcde")

will all (with static array string literals) result in distinct template 
instantiations and object file bloat.

typeof("123") == typeof("abc"), but != typeof("abcd") ?

3. array and aa-literals

["a", "aa"] // error, char[1] and char[2] incompatible
["a":"b", "aa":"bb"] // error

> The question is if it is a compiler bug?

It is by design.

-- 
Oskar