Remove complex and imaginary types?

[Don Clugston]

Walter Bright wrote:
> The issue comes up now and then about why have complex and imaginary 
> types, rather than using structs? All but one of the advantages of 
> having them be core types can be addressed with advancing compiler 
> technology. Getting rid of them will release 6 keywords, and make the 
> core language simpler. Given the increasing complexity of D, this will 
> help.
> 
> The remaining advantage is that of imaginary literals, i.e. the i postfix:
> 
>     3 + 5i
> 
> Assuming we solve the literal problem, existing code would only need to 
> add:
> 
>     import std.complex;
> 
> to acquire complex and imaginary types.

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.