why do you see implicit cast as bad? for me the change from 5 to 5.0f
that you have above *is* an implicit cast, and is exactly what you want.
For 4 * 7 / 2, well that should either be calculated as integer or as
float, it is unlikely that both are correct.
Some languages decided to use a different symbol for integer division
and float division.
without that the thing is kind of ambiguous, and D chooses integer
division, and only later implicit conversion to float.
What I do agree with is that writing generic float literals is
cumbersome (using cast(T)x).
Hello!
Implicit cast is bad, for performance reasons, for clarity, and you can't
call it generic.
With the rule i presented "5 to 5.0f" is not an implicit cast, How?
It is implicit in C derived languages just because 5 is int, it has a
native type, this is language constraint.
In my case 5 is not a native type, and by definition 5 to 5.0f is not an
implicit cast, 5 and 5.0f is the same thing!
For 4 * 7 / 2, yes you are right it was an error on my side which i
corrected with next reply, also i wasn't clear enough.
So, i meant to say there "expect it in the type of T", and that means
since the operator before them expects it in type T,
Treat them as type T, if you can't, pop warning/error, so lets say T is a
floating point type, compiler can do (4 * 7 / 2) operation
in the highest possible precision for the constant folding purposes and
return the result, which will be again a "generic floating point type".
Implicit cast is what happens to stuff that can also be seen as a type X
so natural number -> integers,... implicit cast should not discard
precision, and should maintain the value, and is a *good* thing in
general (if the rules are sensible).
Perfectly fine with me when the rules are really sensible, but isn't the
point of templates, being a template rather than casting?
Is this a generic code then?
uint add(uint m, uint n) { return m + n; }
By implicit/explicit casts i can pass all the types here.
calling foo(0) will pass the "if(isFloatingPoint!(T))" contract, since
0 belongs to all,
but compiler will be unable to resolve the final type which is to be
instantiated.
that gets easily very annoying, even aldor, that basically did all what
you wanted, and complained about unclear overload did an exception for
integers, so that they would default to Int....
Still I find D approach reasonable
If we want add(0) to just work... why it should explicitly be an "int" and
not a byte or real?
For me converting it to highest precision integer would be better choice,
maybe it is the reason why it was "int".
At the time of C there wasn't any integer longer than say int? Sorry if
this sounds naive! :)
Thanks.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
