Remove complex and imaginary types?

[Oskar Linde]

Don Clugston wrote:

> Imaginary numbers were included in D because they are in C99. Why are 
> they in C99?
> It's because of a really obscure situation.
> (a.re + a.im * 1i)*(0.0 + b.im * 1i)
> is not the same as (a.re + a.im * 1i)*(b.im * 1i)
> 
> if a.im or a.re is infinity. In the version where b.re is 0.0, a NaN is 
> created, instead of the correct answer of 0.
> Ultimately this happens because 0.0 can mean either exactly 0, or 'too 
> small to represent' (an underflow).

Thank you for the enlightening information.

> As far as I can tell, D can avoid the need for a pure imaginary type, 
> because *D guarantees constant folding, whereas C does not*. If constant 
> folding is guaranteed, then with any compile-time complex constant, you 
> know if it is a zero, or just an underflow. The problematic 
> multiply-by-approximately zero can be eliminated -- it is known that it 
> is a multiply-by-exactly zero. So we don't need the C99 hack of creating 
> an entirely different type.

But since D doesn't guarantee inlining, I guess there would still be an 
issue with functions that today are overloaded for the imaginary types.

-- 
Oskar