On 20.10.2011 13:12, Manu wrote:
On 20 October 2011 11:02, Don <nos...@nospam.com
<mailto:nos...@nospam.com>> wrote:
On 20.10.2011 09:47, Manu wrote:
Many architectures do not support real, and therefore it should
never be
used implicitly by the language.
Precision problems aside, I would personally insist that implicit
conversation from any sized int always be to float, not double, for
performance reasons (the whole point of a compiled language trying
to supersede C/C++).
On almost all platforms, float and double are the same speed.
This isn't true. Consider ARM, hard to say this isn't a vitally
important architecture these days, and there are plenty of embedded
architectures that don't support doubles at all, I would say it's a
really bad idea to invent a systems programming language that excludes
many architectures by its design... Atmel AVR is another important
architecture.
It doesn't exclude anything. What we're talking about as desirable
behaviour, is exactly what C does. If you care about performance on ARM,
you'll type sqrt(2.0f).
Personally, I'd rather completely eliminate implicit conversions between
integers and floating point types. But that's just me.
I maintain that implicit conversion of integers of any length should
always target the same precision float, and that should be a compiler
flag to specify the desired precision throughout the app (possibly
defaulting to double).
I can't believe that you'd ever write an app without that being an
upfront decision. Casually flipping it with a compiler flag??
Remember that it affects very few things (as discussed below).
If you choose 'float' you may lose some precision obviously, but you
expected that when you chose the options, and did the cast...
Explicit casts are not affected in any way.
Note that what we're discussing here is parameter passing of single
values; if it's part of an aggregate (array or struct), the issue
doesn't arise.
Are we? I thought we were discussing implicit conversion of ints to
floats? This may be parameter passing, but also assignment I expect?
There's no problem with assignment, it's never ambiguous.
There seems to be some confusion about what the issue is.
To reiterate:
void foo(float x) {}
void foo(double x) {}
void bar(float x) {}
void baz(double x) {}
void main()
{
bar(2); // OK -- 2 becomes 2.0f
baz(2); // OK -- 2 becomes 2.0
foo(2); // fails -- ambiguous.
}
My proposal was effectively: if it's ambiguous, choose double. That's all.
