spir wrote:
On Thu, 30 Dec 2010 07:46:19 +0100
Don <nos...@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.
