literals

[Fawzi Mohamed]

On 28-mar-10, at 15:44, so wrote:

>> or give you the "default" precision. And note that this problem is  
>> not what you pointed out initially, but something I gave.
>
> That is it, whole point, what the heck is a default literal or  
> precision in a generic code?

the one to use when things are ambiguos

>> double occupies less space and can use SSE instructions.
> float faster and use half of double, that is not a valid argument,  
> and it is not a valid answer to the problem at hand.
> If i want double i must state it "0.5d", float "0.5f" real "0.5L",  
> we are talking about again "generic" code.
>
> There are too many implicit casts, main reason is because there are  
> default literals, am i wrong?
>
>> invalid code?
>> probably
>>
>> T inv(T)(T m) {
>> 	return 1 / m;
>> }
>
> Now you are just doing it for the sake of argument. :P
> This is another function, for another purpose.

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

>> Integers are the only values that can be represented without any  
>> approximation (unless you resort to rationals, or inefficient  
>> representations that are probably ok only at compile time or in  
>> very specific applications).
>> So generic code should use integers, not floating points.
>> You might argue that the way to get a floating point literal of  
>> type T is ugly:
>> 	cast(T)1.0
>> for example fortran uses 1.0_T, but one can definitely live with  
>> it, anyway normally you should use integers, generic floating point  
>> literals is not really something that is so well defined...
>
> This is not only about floating point types, same applies to integers.
>
> 3 is default "int" right?
> Imagine what happens if it wasn't.
>
> ushort m0 = 30000000000000000000000000000000000; // error
> ubyte m1 = 3; // no implicit cast, fine
> byte m2 = 3; // same
> short m3 = 3; // same
> ubyte m5 = -3; // error
> ushort m6 = -3; // error

I really don't understand your point that is *exactly* what the  
compiler does...

>
> And for the floating point case :
>
> float m = 0.5;
> double n = 0.5;
> real r = 0.5;
>
> What is wrong with this?

nothing and the compiler  accepts it...

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