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

[Andrei Alexandrescu]

Stewart Gordon wrote:
> 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.

I think that the justification should go the other way. A feature's 
existence must be justified, not its removal. Justification of complex 
as a built-in was always rather thin, and Walter is willing to implement 
the few peephole optimizations that obviate it.

> - 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 point was not to reduce the number of keywords.

> - 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.

Cartesian vs. polar is an opt-in, not a must. All operations work with 
both representations, obviously with different performance tradeoffs. A 
library can stick with the representation that is most fit for it, or 
use templates if it is implementation-indifferent.

Does this put more pressure on the library user to choose the best 
representation in a given situation? Sure. But compare with the previous 
situation, in which polar representation-friendly situations and 
applications were consistently the loser.

> - 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.

That's a good point.

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

Please count the number of complex literals you use per 10,000 lines of 
code.

This is an illusory advantage, and ironically one that fosters bad 
style. I was always infuriated when Walter mentioned it.

> - 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?

Because of advancement in compiler technology.

> 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?

I'd say, to paraphrase: "Although built-in complex types are a nice 
idea, there's no need for them to replace the library complex types." I 
took the liberty to replace "while" with "although" because that usage 
of "while" is considered bad style :o).

Keeping both complex types around would further degrade justification 
for the built-in counterpart.


Andrei