literals

[so]

On Sun, 28 Mar 2010 23:46:55 +0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Sun, 28 Mar 2010 14:29:52 -0400, so <so at so.do> wrote:
>
>>> What you want is implicit function template instantiation based on the  
>>> return type.  D doesn't do that, it doesn't even allow overloading  
>>> based on the return type.  However, you can infer the return type  
>>> using auto:
>>>
>>> auto inv(T)(T m)
>>> {
>>>     return 1.0/m;
>>> }
>>>
>>> -Steve
>>
>> Hello!
>>
>> I guess, i am unable to express myself.
>>
>> In code :
>>
>> T inv(T)(T m) {
>> 	return 1.0/m;
>> }
>>
>> If we forget the rules of default literals that C derived languages  
>> have, just for a second.
>>
>> And enforce our own little rule.
>> - no implicit casts
>>
>> With this in mind this code says; i gave you T, give me T in return,  
>> perfectly clear i guess?
>> Now when you call the function with a floating point, real, double,  
>> float..., you will get what you asked for.
>> Now what about other types? Say you call it with a non floating type,  
>> when compiler tries to divide the first thing
>> it will encounter that one of two elements of the operation is a  
>> non-float, since we enforced a rule, it gives warning or error.
>
> What you are asking for is a template instantiation that depends on  
> instantiating itself.  How about a function like this?
>
> void foo(int x);
>
> T inv(T)(T m) {
>     foo(m);
>     return 1.0/m;
> }
>
> How do you know what type to use for T?  It's simple when you make inv a  
> one-liner, there is only one thing to look at.  But as you start making  
> the function more complex, then it's impossible to tell what the user  
> actually wants.   In this instance, T must be implicitly convertable to  
> int, but also must be a floating point type.  Clearly there is an error  
> here, but where is it?  This is called ambiguity, and to avoid it, the  
> compiler makes a decision, right or wrong, based on the literal used to  
> call the function.  It expects you, the user, to help out when it  
> doesn't make the right one.  I don't think it's too much to ask.  It's  
> simply a tradeoff between being an all-powerful oracle-like compiler and  
> being a simple-to-write compiler.

I don't think a language/compiler should make premature decisions when an  
ambiguity happens,
What is warning or error mechanism for then?
In your case, we have a rule at hand, and you broke it. That should  
require an explicit cast,
Also, when you have a framework, you would have the T version of the "foo"  
right? I guess i am missing something here.

>
> What the compiler sees when deciding to instantiate is this:
>
> T inv(T)(T m) {...}
>
> And it makes a decision.

I am perfectly fine with that.

>
> If you have a problem with writing inv(5.0) instead of inv(5), then  
> maybe D just isn't for you.
>
> -Steve

I am not sure what you mean really? You mean the other way around? i want :

inv(5.0f), inv(5.0d), inv(5.0L)
or
T x; inv(x); // where T is floating point type.

Thanks.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/