PROPOSAL: Implicit conversions of integer literals to floating point

[spir]

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.

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, but it's still weird, annoying, and difficult to get right. This is also bug-prone; and the issue may not show on testing, esp if one uses explicitely typed vars as arguments (instead of plain literals):
	void f (char c) {writeln("c");}
	void f(int i) {writeln("i");}
	f(0x1f);	// "i"
	char DEL = 0x1f;
	f(DEL);		// "c"

Also, I had to discriminate 2 constructors, one accepting a string and an uint, the other accepting a string and an element which happened to be a char. Needed to add a third fake param. The issue became even clearer when I generalised the type to a template in which the Element type could be anything.


denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com