Things that may be removed

[Mikola Lysenko]

Stewart Gordon Wrote:

> "Mikola Lysenko" <mikolalysenko at gmail.com> wrote in message 
> news:giouum$1fnk$1 at digitalmars.com...
> > ifloat, idouble, ireal, cfloat, cdouble ... and of course creal
> 
> Why?
> 
> http://www.digitalmars.com/d/2.0/builtin.html
> 
> Stewart.
> 
> -- 
> My e-mail address is valid but not my primary mailbox.  Please keep replies 
> on the 'group where everybody may benefit. 
> 

Please do not misunderstand -- I am not against builtins.  Dynamic/associative arrays along with all their fancy syntax for iteration, concatenation and slicing, are my favorite features in D.  I think that dynamic arrays alone ought to be enough to sell D to any sane programmer, and I really wish more languages would adopt similar features (I especially miss it when I'm programming in CUDA.)  Dynamic arrays are such a successful innovation that pretty much every D program around uses them (at the very least in main(char[][]) ).

On the other hand, complex builtins are largely ignored.  Like array-types, complex builtins were an early experiment in D's design (dating back to the bad-old days before operator overloading or templates were even on the drawing board!)  However, unlike arrays they are almost never used.  To quantify just how rare, I tried the following google code search experiment:

Searches:
http://www.google.com/codesearch?q=lang%3Ad
http://www.google.com/codesearch?q=cfloat+lang%3Ad
http://www.google.com/codesearch?q=cdouble+lang%3Ad
http://www.google.com/codesearch?q=creal+lang%3Ad

Results:
D: 43,000 items
cfloat: 643 items
cdouble: 594 items
creal: 725 items

Even as low as these numbers are, they are still highly inflated inflated.  After painstakingly going through each result, I can confidently claim that all instances of the complex data types indexed by google fall into one of the following categories:

1. Code from Tango/Phobos' math module
2. A special case in a generic template container
3. A special case in a generic IO module
4. Part of a D lexer

Notably absent from this list are cases where complex types were used for actual arithmetic.  In fact, it seems that the only consequence of the complex data types in real D is the generation of superfluous special cases !!!  (I encourage anyone else to try repeating this experiment if they think I'm being hyperbolic.)

Of course, it is true that builtin-complex does have some advantages.  The one which is claimed on the rationale page is that the syntax is nicer.  This is probably true, but I am unconvinced that it matters.  From my experience, I can think of only one time where I actually found this feature useful - when I was writing a Mandelbrodt set viewer to test out the complex number syntax in D.  At any rate, I suspect that clever hackers in the D community can probably do just as well, if not better, using clever template language tricks.

The other major argument for complex numbers as a builtin is the potential for low level optimization.  To be honest, I have no idea how this actually works.  I can't think of any optimization a compiler could do with a builtin complex that it couldn't just as easily pull off on a templatized-struct.  I don't feel that this claim holds much water, but I wouldn't mind being enlightened if someone could demonstrate otherwise.

On the other hand, templatized complex numbers have several unique advantages.  They can be easily extended to incorporate high precision or rational arithmetic (which is useful in some audio processing applications.)  As an algebraic tool, the basic complex class can be exploited to build up more advanced algebraic types, such as Clifford algebras.  Finally (and most importantly), the present template system would treat them like just another struct, thus reducing enormous amounts of utterly redundant created to deal with 6 extra primitive types.



In summary, here is how they stack up:

Builtin Complex:
Pros:
+ Syntactic sugar for imaginary literals
+ Potential for more advanced optimizations

Cons:
- Rarely used (see above)
- Language bloat
- Results in redundant interface code (special cases for IO, most templates, etc.)
- "Imaginary Real" is a ridiculous name


Template Complex:
Pros:
+ Simplifies language
+ Easier template interfaces (complex!(T) vs. ifloat, idouble, ireal, cfloat, cdouble, creal)
+ Supports rational, exact and variable precision arithmetic
+ Useful for implementing several algebraic systems, (Gaussian integers, Clifford Algebras, quaternions)

Cons:
- Would require changing D in ways that break some existing code



Conclusion: Complex builtins were an interesting idea, but in practice they're rarely used. Phasing them into a library template would eliminate a bunch of redundant code, simplify the language in a meaningful way and improve flexibility.  Win all around.

-Mik