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.
