Sergey Gromov wrote:
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
A) Yes, it works the way that you say. This damages it's utility.
B) I'm replying to a question as to how typedef could reasonably be
extended.
