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
