Problems with PR 21210

[Gabriel Dos Reis]

"Nathan (Jasper) Myers" <ncm@codesourcery.com> writes:

| On Tue, May 31, 2005 at 03:20:29PM -0700, Mark Mitchell wrote:
| > I'm not sure what other areas of concern arise, with respect to this PR, 
| > which is just about the core language.
| > 
| > There are indeed other questions, though, like:
| > 
| > 1. Overload resolution
| > 
| >   void f(std::complex<double>);
| >   void f(__complex__ double);
| > 
| > 2. Should we have overloads of "sin" (and so forth) for "__complex__" 
| >    types?
| 
| The Intent of the Committee was that compilers would open-code complex 
| and val_array objects if there was anything to be gained by it.   
| That is, std::complex<> and __complex__ ought to one and the same 
| type.   I hope the C committee has not given them such different 
| semantics that it's impossible.


I don't know on which side to put the blame (and I'm not sure that
helps :-)).  Most certaninly there is a variation in the semantics of
operations when applied to complex data types in both languages, and I
do not believe there is any uniformization possible at this point
(though I would like to be proven wrong).  Because C++ uses templates,
there are things you can write in C99 that won't have necessarily the
same semantics in C++.  Furthermore, C++ has a general templates and 
three explicit specializations (float, double, and long double).
Each of those specializations is slightly different in the set of
implicit conversion it supports.  For exmaple, you could implicitly
convert _Complex double to _Complex float in C99, whereas such things
do not exist in C++: they ought to be explicit.  C99 has "usual
promotion" rules applied to _Complex T, whereas such things do not
exist in C++ -- therefore introducing variations in which functions
get selected in overload resolution.

Unless the compiler front-end is going to support member selection on
_Complex, i.e. support the notation .real() or .imag(), on _Complex
and allow for arbritrary numeric T in _Complex, I would not support
the introduction of compiler magic that blends _Complex and
std::complex.   And if that complexity is going to be taken, then I would 
rather see something the lines ofwhat Jason suggested earlier.

If we are going to introduce a notion of "typedef template", we rather
look at the template alias proposal that is already locked in for C++0x.

__complex__ was choosen as an implementation detail that increases, to
some extent, compatibility with C99.  It wasn't intented to have a
more invasive impact on the language nor on the library itself.

-- Gaby