On Mon, 29 Mar 2010 09:20:56 -0400, so <s...@so.do> wrote:
You are right, inv is a dumb function, we need a real world example.
Say we have a function with 2 overloads, which might be the reasons of
precision, performance...
float foo(float m) {}
double foo(double m) {}
Now we need to call this within a generic code.
void test(T)(T m) {
return m * foo(0.3);
}
Since 0.3 is a double, double version will be called, so we should use
foo(cast(T)0.3), right?
When the function foo is a popular one, what am i going to do? anything
other than casting at each occurrence?
with functions like foo, code becomes like...
void test2(T)(T m) {
T n = foo1(cast(T)0.3) / foo2(cast(T)9);
....
...
}
OK, I see the issue now. The syntax for declaring that a literal is the
type of T is too verbose. This is different than what I thought you
wanted.
I agree this isn't the best situation. It's good that it is possible, but
we should strive to find a better way.
Sorry for the noise from misunderstanding.
As for the better way, one possibility is using C++-style value type
constructors:
float(0.3)
This provides a way to have T be a user-defined type as well (define
static opCall or a constructor)
So the test function would look like this:
void test(T)(T m) {
{
return m * foo(T(0.3));
}
It would be nice to say "in this function, assume numeric literals are of
type T," but that might be too specific a solution (could only apply to
builtin types). I don't think it's feasible for the compiler to infer
what type it should use.
-Steve
