Sun, 11 Jan 2009 18:09:15 -0800, Charles Hixson wrote:
> Well, my use case just involves being able to use library function with
> the proper base type. (I.e., int instead of long or byte when I do
> typedef int LocalType;
> LocalType t;
> File f;
> f.write(t);
>
> I'll grant that I *can* use alias for such a purpose, but that doesn't
> distinguish between LocalType and ArrayIndex in routines defined for
> those types. E.g.:
> typedef int ArrayIndex;
> void zeroIndex(out ArrayIndex ai) { ai = 0; }
> zeroIndex(t);
>
> Should throw an error. If I'm using alias it doesn't (and shouldn't);
Well, I presume File.write() has many overloads, including one for int
but none for LocalType. When aliasing, the LocalType *is* an int, it
matches exactly File.write(int) and the compiler is happy.
However, with a typedef, LocalType is a distinct type. Yes it casts to
int implicitly, but likewise it casts implicitly to char, short and
long. So compiler gets a whole load of File.write() functions matching
with conversions, and fails because of the ambiguity.
That's how the language works, and it's pretty consistent IMO. What you
can do is:
f.write(cast(int)t);
or use templates to generalize:
auto fileWrite(T : LocalType)(File f, T v)
{
return f.write(cast(int)v);
}
auto fileWrite(T)(File f, T v)
{
return f.write(v);
}
fileWrite(f, t); // OK
fileWrite(f, 15); // OK
When we get generic function calls you'd be even able to write:
void write(File f, LocalType l)
{
f.write(cast(int)l);
}
f.write(t); // OK, write(f, t) is called
