The following code does not compile:
struct S {
void foo(in char[] s) {}
void foo(in dchar[] s) {}
}
void main(string[] args) {
S s;
s.foo("a");
}
The second overload should not even be considered.
Comment #1 by jarrett.billingsley — 2008-09-20T15:44:11Z
"string literals" do not have a type; they are, in some ways,
polysemous. They are considered char[], wchar[], or dchar[] based on
where they're used. If they're used in a situation where it could go
either way (such as this overloading case), it's an error.
The solution is simple: affix a 'c', 'w', or 'd' to the end of the
string literal to give it an explicit type.
Comment #2 by andrei — 2008-09-20T17:25:52Z
Even with polysemy, vocables may have a principal meaning. For example "1" is polysemous because it fits byte, ubyte etc. but absent any constraint it will prefer to be an int.
auto i = 1; // i's type is int
As discussed with Walter, strings are also easy to acquire a principal meaning. One possibility discussed is that strings with only ASCII characters to have invariant(char)[N] as principal type. In fact the N should be dropped too for a number of reasons. So "a" should have principal type invariant(char)[]. (If a constraint is present, no problem.)
The exaggerated ambiguity of string literals has caused much grief to many people, it's about time to fix it.
Comment #3 by jarrett.billingsley — 2008-09-20T17:49:20Z
Amen to dropping the fixed-sizedness of string literals. I suppose determining the type based on the smallest type that can represent the data without using multibyte encodings is reasonable enough, and you're right, it fits in with the way it works for ints.
Comment #4 by dfj1esp02 — 2008-09-30T03:09:57Z
(In reply to comment #2)
> One possibility discussed is that strings with only ASCII characters to have
> invariant(char)[N] as principal type.
What's up with ASCII? char in D is utf byte.
> In fact the N should be dropped too for a number of reasons.
ololo templates?
Comment #5 by yebblies — 2011-06-15T07:51:41Z
From Andrei's comment on bug 2606
void f(const(char)[] s) {}
void f(const(dchar)[] s) {}
void main()
{
f("abc");
auto a = "abc";
f(a);
}
Comment #6 by yebblies — 2011-06-15T07:51:48Z
*** Issue 2606 has been marked as a duplicate of this issue. ***
Comment #7 by yebblies — 2011-06-15T07:52:05Z
*** Issue 4592 has been marked as a duplicate of this issue. ***
Comment #8 by clugdbug — 2011-06-17T01:19:16Z
*** Issue 4353 has been marked as a duplicate of this issue. ***
*** Issue 6639 has been marked as a duplicate of this issue. ***
Comment #11 by yebblies — 2012-02-19T05:16:59Z
The pull is still valid (if in need of a rebase) but the solution needs a decision from Walter on how the match level problem is going to be solved in the future.
See issue 4953 for another example.