On Wed, Mar 14, 2012 at 02:44:40PM -0400, Steven Schveighoffer wrote:
> On Wed, 14 Mar 2012 14:16:11 -0400, H. S. Teoh
> <hst...@quickfur.ath.cx> wrote:
>
> >What I want is to force the compiler to deduce S=dstring when I
> >declare func(S)(S) and call it as func("abc").
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4998
>
> Please vote or contribute your thoughts.
[...]
Ahhh, thanks for pointing this out. That is exactly the problem I'm
struggling with.
I guess the motivation of my original question wasn't clear. I should
say that I ran into this problem in the context of my AA implementation.
I've successfully implemented Andrei's suggestion: int[wstring] will now
accept wchar[], const(wchar)[], in addition to wstring in .get,
.opIndex, etc.. It will implicitly call wchar[].idup when it needs to
create a new hash entry. (Ditto with dstring, and with any immutable
array key type.)
To implement this change, opIndexAssign now looks like this:
struct AssociativeArray(Key,Value) {
...
void opIndexAssign(K)(in Value v, in K key)
if (isCompatWithKey!K)
{
...
}
}
The template isCompatWithKey basically checks if K can be implicitly
converted to Key, or has an .idup method that returns something that can
be implicitly converted to Key.
However, this change broke this code:
AssociativeArray!(wstring,int) aa;
aa["abc"] = 123; // error: compiler deduces K as string,
// so isCompatWithKey!K fails: string
// can't implicitly convert to wstring
Whereas before, when opIndexAssign looked like this:
void opIndexAssign(in Value v, in Key key)
{
...
}
everything worked, because the compiler deduces the type of "abc" as
wstring since Key==wstring.
Now you have to write:
aa["abc"w] = 123;
which isn't the end of the world, I suppose, but it's not very nice, and
also breaks existing code that depended on the compiler automatically
deducing that typeof("abc")==wstring.
T
--
There are three kinds of people in the world: those who can count, and those
who can't.
