literals

[so]

> 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/