PROPOSAL: Implicit conversions of integer literals to floating point
Don
nospam at nospam.com
Thu Dec 30 12:17:02 PST 2010
spir wrote:
> On Thu, 30 Dec 2010 07:46:19 +0100
> Don <nospam at nospam.com> wrote:
>
>> This problem has already hit Phobos. We inserted a hack so that sqrt(2)
>> will work. But exp(1) doesn't work.
>> Note that the problems really arise because we've inherited C's rather
>> cavalier approach to implicit conversion.
>
> I'm unsure of the problem you point to. There can be two, imo, possibly interrelated:
> * A function (like sqrt) should accept both floats (certainly via conversion).
> * It is considered acceptable to write an int literal (1) where a float (1.0) is intended.
> If the issue you point is the latter, then a simple solution is for clients of float/double/real interfaces to write correct literals. But this breaks with a long-standing practice (esp in C-like languages.
The latter. If it is considered acceptable to write an int literal when
meaning a floating-point literals, then a tie-breaking rule is required.
If it's not acceptable, then we shouldn't allow it at all.
>
> I have faced several _possibly_ similar issues about casts/conversions between various char types on one side and signed/unsigned integer types on the other.
>
> Example:
> void f (char c) {writeln("c");}
> void f(uint i) {writeln("i");}
> f(0x1f); // f(DEL)
> writes "c". But if the second param type is int, it writes "i". I'm aware this correctly follows conversion rules,
Does it? I don't see how 0x1F converts to char without an implicit
conversion. Looks like a bug to me.
More information about the Digitalmars-d
mailing list