literals

[so]

> the one to use when things are ambiguos

What ambiguity you are talking about?
It is generic code, everything known.

> really the compiler cannot parse your function, and I can't either, to  
> me what you meant is the code I wrote.

So you are saying a compiler is unable to parse this :

T inv(T)(T m) {
	return 1.0 / m;
}

And perfectly fine with parsing this one?

T inv(T)(T m) {
	return 1 / m;
}

A coder who has the basic knowledge of "you can't take an inverse of an  
integer" wouldn't write the second code,
and when he does, he should understand if the second code pops the error  
when he pass a floating point argument, inv(5.0)
Why? Remember the rule again, no implicit casts.

> nothing and the compiler  accepts it...

Now you don't even read what i write, what is the point replying then,  
move on. :)

>
> It seems to me that you don't even know the language, and you want find  
> "problems" in it that aren't there.
>
> Your code is invalid, I gave a valid code, which I think solves the  
> problems you are trying to illustrate, and argued about the pitfalls of  
> "generic float literals" (no language that I know of has good support  
> for them, and that in D you would write with cast(T)literal).
>
> In D the return type of a function (like in many other languages) is  
> determined by its arguments, so it makes no sense to having it  
> determined from operations in its inside, like 1.0/m, T is determined  
> *before* the call and independently from what happens inside the function

I am not sure if i should answer you with the attitude of yours but lets  
have it.
T is determined before the call, did i say anything against or i was the  
one proposing improvement over it? :)

T is determined before the call yes, when i call inv(4.0f)
it will be "1.0f/4.0f", with "zero implicit casts"
in your case it will be "1/4.0f" which is either implicit cast or an  
error/warning.

Thanks.

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