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