literals
Steven Schveighoffer
schveiguy at yahoo.com
Mon Mar 29 07:35:05 PDT 2010
On Mon, 29 Mar 2010 09:20:56 -0400, so <so at 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
More information about the Digitalmars-d
mailing list