On Fri, 29 May 2015, Michael Dietrich wrote:
> Zitat von Brad Chamberlain <[email protected]>:
>
>> Where some options are:
>>
>> a) The compiler should complain that there isn't an appropriate overload
>> of foo(). I.e., coercions from int(32) to real(32) are lossy, so
>> should not happen automatically.
>>
>> b) The int(32) is coerced to a real(32) and foo() is called
>>
>> c) Same as (b), but a compile-time warning is also generated warning of
>> the potential for loss of data.
>>
>> Again, we're curious for thoughts on this question.
>>
>
> I would prefer option c) for avoiding unwanted effects.
I would second that. Or am I third, or fourth?
> C/C++ usually does option b) (at least GCC and G++) and this is a common
> source of runtime-errors for beginners or for people who program too
> fastly. ;) b) may have an educational use but in practice I don't find
> this appropriate.
>
> There may be seldom cases where this situation appears intentionally
> so I'm not favor of a) which has been suggested before.
Ditto.
> But this depends on Chapel's philosophy about how much freedom to give
> to the programmer.
If you are too strict, you loose proponents of the language.
You can build the strictness into compile time options anyway.
If you have to work with multiple versions of a code, i.e. a 32-bit
version and a 64-bit version, automatic promotion is a nightmare.
Having said that, given that I am mandating that, in 32-bit mode, the
declaration
var x : real;
is 32-bits, I wonder what is the type of a floating point constant is,
var y = 4.5678912345678987654321;
One would have to say 32-bits but the calculation is done by the compiler
as accurate as it can go before it stuffs the value into a real(32). And
again, the compiler is free to complain about loss of precision.
And again, if such decisions are compiler option, that keeps everybody
happy.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
