Replacing built-in complex? What's this about?

[Stewart Gordon]

The plan to remove the built-in complex and imaginary types has finally 
come to my attention.  I seem to have somehow blinked and missed the 
discussions earlier this year about it.

The motives seem to be along the lines of reducing compiler complexity 
(not sure if any pun has been intended) and freeing up keywords.  But is 
it really worth it?

I've noticed that std.complex is still heavily under construction. 
Which would explain why it doesn't yet have pure imaginary types, among 
other things.

My thoughts are:

- Built-in complex types can't be that hard to implement.  That Walter 
is thinking about removing them sounds to me like a sign that D is 
losing its simplicity and trying to cut corners to get it back.

- If the point is to cut D's number of keywords, this can be done 
without throwing the whole feature out of the window.  One way, inspired 
by the const/invariant notation, is

     complex(real)
     imaginary(double)

That said, the existing c* and i* keywords STM no big deal, considering 
that they aren't standard English words, and so not that likely that 
somebody will want to use them for his/her own purposes.

- The current built-in complex is relatively simple.  Libraries have 
only a few complex types to deal with.  The added complexity of 
std.complex means that library programmers will have to consider 
supporting both cartesian and polar representation, among possible other 
things.  Using templates just to cover all possible cases would prevent 
the functions from being virtual.

- Link compatibility with C has been given as an important feature of D. 
  Since C has complex and imaginary types, can this work fully if D 
doesn't?  It might get even trickier when we consider link compatibility 
with C++, which must support function overloading.  Even if C++ doesn't 
yet have complex/imaginary, it will probably get them soon, and FAIK 
some C++ compilers probably already have it as an extension.

- The imaginary literal notation and resulting concise notation for 
complex numbers are nice ideas.  It would be sad to lose these.

- D has the potential to supersede Fortran as a scientific programming 
language.  Indeed, "Numerical programmers" is one entry in the "Who D is 
For" list.  So if Fortran has an excuse for built-in complex, why not D?

To conclude, while library complex types are a nice idea, there's no 
need for them to replace the built-in complex types.  IMO it would work 
well to keep the built-in complex types, and have std.complex available 
as an alternative for when you want more power than that provided by the 
built-in types.  What's more, std.complex should provide conversions 
between its complex types and the built-in ones.

Thoughts?

Stewart.