Remove complex and imaginary types?

[John Reimer]

On Mon, 07 Jan 2008 09:05:45 +0100, Don Clugston wrote:

> There is also the advantage of standardisation, although I don't think
> it's a strong argument -- AFAIK, C++ hasn't had a problem with multiple
> incompatible definitions of Complex.
> I imagine that game programmers ask, if complex numbers are built-in,
> why not quaternions too?
> 
> I think the argument for pure imaginary types is extremely weak. They
> are very annoying to work with, because they aren't closed under
> multiplication. This is a nasty property to have in a built-in type.
> 
> Suppose you're writing a generic function product(T)(T[]) which returns
> T[0]*T[1]*T[2]*... What's the return type? Suppose T is idouble. Then if
> the number of elements in T is odd, the return type should be idouble,
> but if it's even, the return type should be double! You could promote it
> to complex with a construction like typeof(1?T*T:T), but that's
> inefficient, and negates most of the benefits of having a imaginary
> type.
> 
> As far as I can tell, the imaginary types could be removed even if the
> literal problem was not solved (the compiler could continue to keep
> track of imaginary literals internally, but promote them to complex
> whenever a type is required). But a solution to the literal problem
> would be impressive.


I agree with Don (how could I not? :D), although I really have little 
understanding of the technical internals.

Several years ago, when I first started using D, I was working on an 
electronics engineering course.  One of my first bug reports was on D 
complex arithmetic. So it may be useful in some special fields, but I 
really don't see how it is a critical special case in D; a suitable 
replacement using structs would probably be more than sufficient.  

Furthermore, creal and ireal came across as an oxymoron.

-JJR