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