complex change idea

[Jim Thomas]

Mail*Link(r) SMTP               complex change idea
I am soliciting opinions about the following possible change to "Complex C
Extensions" (X3J11.1/93-048).  This change would be intended to alleviate the
overhead of imaginary types for those (non-IEEE) implementations that do not
treat special values (infinities, NaNs, and signed zeros) in a manner that
would benefit from imaginary types.  I am particularly interested in whether
this approach would overcome the major objections to "Complex C Extensions"
and allow us to move forward with one complex proposal for C language.

1. Make the imaginary types an optional part of <complex.h>.

2. Add an implementation macro identifying support for imaginary types.

3. Define the "imaginary unit" I to be imaginary or complex according as
imaginary types are or are not supported.

4. Require support of imaginary types for IEEE implementations.

5. Note that this approach would be suitable for C++ too.

6. Note that the language rules in "Complex C Extensions" are complete without
imaginary types.  Then the conversion rules are equivalent to the earlier Cray
proposal where real operands were not promoted to complex.

7. Note that code using the "imaginary unit" I but not explicitly mentioning
imaginary types could port between implementations that do and do not support
imaginary types, though, of course, the effect of special values would be
different.  On implementations that support imaginary types, such code would
benefit from imaginary types implicitly through the imaginary unit.

8. Note that code written with explicit mention of imaginary types largely
could port to implementations that do not support imaginary types by including
typedefs of xxx_imaginary to xxx_complex. 

-Jim