Issue 3686 - common type of imaginary and non-imaginary should be complex

[yebblies]

Issue 3686 - common type of imaginary and non-imaginary should be complex

Update implicit conversion tables and disable remove special casing from AddExp and MinExp.

http://d.puremagic.com/issues/show_bug.cgi?id=3686

[donc]

Does this deal with *, / correctly?
imaginary * real is imaginary, not complex.

[yebblies]

Yes, they seem to be. The type of most operations is special cased for mixed real and imaginary arguments. I removed the special casing on addition and subtraction as they should follow the common type rules.

[donc]

Having thought about this a bit more, I'm certain the conclusion of the bug report is wrong --
cond ? real : imaginary
should simply be rejected. If it occurs in code, it's almost certainly a bug. For example, cond ? sqrt(-1.0) : 2i;
Note that real does NOT implicitly convert to complex (and nor does imaginary).
The reason for imaginary types to exist is that they represent complex numbers where the real part is exactly zero -- not +0.0 or -0.0. This can't be represented perfectly in a complex type.

More importantly, I don't know how that behaviour can be implemented when Complex and Imaginary become built-in types.

[yebblies]

I'll trust your expertise on this. Anything is better than the common type of float and ifloat being float.