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.
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
